FinClaw V1 Multi-Agent Coordination Plan

状态：Accepted R1 / Multi-Stack Coordination 日期：2026-05-16（R1 修订当日）项目：FinClaw 文档级别：项目级协同实施计划上游协议：v1-multi-agent-execution-protocol.md（规则）上游决策：v1-engineering-kickoff-decisions.md 上游里程碑：v1-execution-plan-and-milestones.md 上游路由：personal-domain-admin docs/03-routing-matrix.md（通用 stack 路由）

R1 修订要点（2026-05-16）：本文档自 V0 (Cursor-Agent-A~F 6 角色单 stack 模型) 升级到 R1 (Multi-Stack 模型)。R1 的核心分工：

Cursor (Opus 4.6/4.7)：复杂任务执行 + Review/审计闭环（L2 Reviewer，不再作为常规 sub-packet 主力）；

Codex (GPT-5.5 + gpt-codex-5.3)：常规 sub-packet 工程化主力（"量大管饱"）；

OOSO (4 角色)：plan + 执行 + 深度 + 批量四象限的 coding 主力（Prometheus / Atlas / Hephaestus / Sisyphus）；

CTRL：项目发起人手工驱动决策 / 合并 / 跨 stack 调度；

测试 / 其他职责按 §2A.3 + §2A.4 路由表分配。

R1 主要修订节：§2 Agent Role Matrix + §2A Task Routing Decision Tree（新增）+ §3 Worktree Configuration + §4 Phase-by-Phase Parallel Plan + §6 Launch Commands + §8.4 Cross-Stack Failure Recovery（新增）+ §8.5 Review-Finding Anchor 模板（新增）。其它节（§5 Hand-off Flow / §7 Monitoring / §9 Quality Gates）保持 V0 表述，但其中 "Cursor-Agent-A~F" 引用应就近替换为 R1 角色名（CUR-REV / CDX-MAIN / CDX-CODE / OOSO-PROM / OOSO-ATLAS / OOSO-HEPH / OOSO-SISY）。

1. Purpose

v1-multi-agent-execution-protocol.md 定义了规则（context 预算、worktree 隔离、hand-off 协议、冲突解决）。

本文件定义计划：

哪些 Agent 在哪个阶段被分配哪些 sub-packet；
各 Agent 的 worktree 设置与启动指令；
各阶段并行度选择；
同步点与监控指令；
失败时的恢复路径。

本文件是具体的执行方案；规则违反必须回到协议。

2. Agent Role Matrix

本节由 2026-05-16 V1 多 Agent 分工修订替换 V0 版：旧版 Cursor-Agent-A~F 6 角色作为工程化主力的设定已废弃。V1 采用 Cursor as Reviewer + Codex / OOSO as Coding 主力 的双层分工模型。

2.1 角色分层（V1 锁定）

分层	主责	不该做的事
L1 Controller	决策 / 裁决 / 合并 / 跨 stack 调度	不直接 coding（除非紧急 hotfix）
L2 Reviewer & Complex Solver	复杂任务执行 + 跨包 review + 审计 + 高难度 spike	不做高重复 / 量化 coding
L3 Coding 主力	大部分常规 sub-packet 工程化落地	不做 architectural 决策（决策回 L1）；不做最终 review（review 回 L2）
L4 Background Worker	长周期异步任务（治理库分析 / batch 数据处理）	不动工程仓库代码

2.2 Agent Capability Matrix（V1 锁定）

Role ID	分层	Stack / 模型	主责场景	MCP 接入路径
CTRL	L1	Cursor + Opus 4.7（项目发起人手工驱动）	决策记录 / kickoff 修订 / PR 合并 / 跨 stack 裁决 / handoff anchor 审核	n/a（项目发起人本人）
CUR-REV	L2	Cursor + Opus 4.6 / 4.7	(a) 复杂跨包 sub-packet（如 Refresh Diff View 跨 B-2 / B-3 / B-4 / B-5 / B-6 五份设计）；(b) 每个 sub-packet 完成后强制 review 闭环（acceptance criteria 校验 + 边界守门审计）；(c) 安全 / 隐私 / 边界硬约束审计；(d) 跨 stack 接力点的 handoff anchor 一致性裁决	主：Cursor IDE；MCP：`codex.` / `hermes.` / `openclaw.*` 调度下游
CDX-MAIN	L3	Codex CLI + GPT-5.5（"量大管饱"主力）	大部分常规 sub-packet 闭环（CRUD endpoint / models / persistence / SSE event / 常规前后端组件 / 测试用例填充）；与 CUR-REV 形成 "Codex 写 → Cursor review" 的标准闭环	主：Codex CLI；从 Cursor MCP `codex.*` 调度
CDX-CODE	L3	Codex CLI + gpt-codex-5.3（coding-specialized）	深度 coding 任务（复杂算法 / 性能敏感路径 / refactor / 跨文件大段重构）；与 CDX-MAIN 区分点：MAIN 走宽度，CODE 走深度	主：Codex CLI（切模型）；从 Cursor MCP `codex.*` 调度（model: `gpt-codex-5.3`）
OOSO-PROM	L3	OpenCode + OOSO / Prometheus = Plan Builder = gpt-5.5	sub-packet 拆分前的技术方案 plan 建模 / 接口契约草稿 / 选型权衡（与 CTRL 协同；不做最终决策）	主：OOSO（OpenCode）；从 Cursor 走 Shell + `oh-my-opencode run --json --role prometheus`
OOSO-ATLAS	L3	OpenCode + OOSO / Atlas = Plan Executor = Kimi K2.6	按 PROM 产出的 plan 标准化执行常规 coding；适合中等粒度 sub-packet（5-12K token 范围）；与 CDX-MAIN 并行可用	主：OOSO；从 Cursor 走 Shell + `oh-my-opencode run --json --role atlas`
OOSO-HEPH	L3 / L2	OpenCode + OOSO / Hephaestus = Deep Agent = gpt-5.3-codex	复杂深度 coding（大型 refactor / 复杂 migration / 跨多模块测试编排）；可作为 CUR-REV 的 coding 委托手；需要 CUR-REV 出具明确 design 后才接入	主：OOSO；从 Cursor 走 Shell + `oh-my-opencode run --json --role hephaestus`
OOSO-SISY	L3	OpenCode + OOSO / Sisyphus = Ultraworker = Kimi K2.6	高重复 / 量大 / 标准化任务（测试用例批量填充 / docstring 批量补全 / 一致性扫描 / batch refactor 跟踪）；适合 50+ 文件级别的批量操作	主：OOSO；从 Cursor 走 Shell + `oh-my-opencode run --json --role sisyphus`
CDX-AIFL	L4	Codex CLI + GPT-5.5（背景任务，PID 10466，已启动 2026-05-16 09:56）	aifinlab Root Skills 异步分析（D-09）；产出全部写治理库 `reference-experience/aifinlab-root-skills-taxonomy/`；与工程仓库物理隔离	已在 nohup 中运行；监控走日志 tail

OOSO 4 角色对照参考：OpenCode + OOSO 体系本身约定 4 个 fixed agent role，其与模型的绑定不由本项目决定，沿用 OOSO Integration Guide（~/Programs/opencode-integration/OOSO_INTEGRATION_GUIDE.md）的官方约定：

Sisyphus = Ultraworker（Kimi K2.6）→ 量大重复
Hephaestus = Deep Agent（gpt-5.3-codex）→ 深度 coding
Prometheus = Plan Builder（gpt-5.5）→ 方案建模
Atlas = Plan Executor（Kimi K2.6）→ plan 标准化执行

如 OOSO 上游修改 role↔model 绑定，本表必须同步更新（不要在本项目内私自改名）。

2.3 与 personal-domain-admin 路由表的关系

本表是 personal-domain-admin 03-routing-matrix.md 在 FinClaw V1 项目内的特化版：

通用路由（Cursor → Codex / OOSO / Hermes / OpenClaw 选谁）仍以 routing-matrix 为准；
FinClaw V1 项目内的具体 sub-packet 分配由本表 §4 + §2A 决策树补强；
本项目内出现路由表未覆盖的新场景时，先在本文档登记，待稳定后回流到 routing-matrix。

默认假设：Cursor 多 worktree 不再为每个业务域开一个角色（V0 假设已废弃）；改为以 「stack 隔离 + 任务路由」 模式分配 worktree（见 §3）。同一时间常态下：CTRL 1 个 + CUR-REV 1-2 个 + Codex 后台 1-2 个 + OOSO 1-2 个 + CDX-AIFL 后台 1 个 = 5-7 个 agent 并发。

2A. Task Routing Decision Tree

目的：项目发起人 / CTRL 在分配每个 sub-packet 之前，按本节决策树挑选合适的 agent。本节是 §2 角色矩阵的操作化界面。

2A.1 决策树（按问题顺序回答）

问题 1：这个任务是否涉及 V1 边界硬约束 / 隐私 / 安全 / 跨多份设计文档（≥3 份）/ 架构决策？
  ├─ 是 → 路由到 CUR-REV（Cursor + Opus 4.7）
  │      └─ 如 CUR-REV 在执行中需要 coding 委托，可拆出深度 coding 子任务给 OOSO-HEPH，自己保留架构 / 边界守门职责
  └─ 否 → 进入问题 2

问题 2：这个任务是否是 5-12K token 的常规 sub-packet（CRUD / models / API endpoint / SSE event / 常规 UI 组件 / 测试用例填充）？
  ├─ 是 → 进入问题 2a
  └─ 否 → 进入问题 3

问题 2a：sub-packet 是否需要先做技术方案 plan / 接口契约草稿 / 选型权衡？
  ├─ 是 → OOSO-PROM 先出 plan → 然后 OOSO-ATLAS 或 CDX-MAIN 执行
  └─ 否 → 直接路由到 CDX-MAIN（量大管饱）

问题 3：这个任务是否是高重复 / 量大 / 标准化的 batch 操作（如 14 个 sub-packet 的 frontmatter 同步 / 50+ 文件 docstring 补全 / 一致性扫描）？
  ├─ 是 → 路由到 OOSO-SISY（Ultraworker = Kimi K2.6）
  └─ 否 → 进入问题 4

问题 4：这个任务是否是深度 coding（复杂算法 / 性能敏感路径 / 大型 refactor / 跨多模块 migration）？
  ├─ 是 → 路由到 OOSO-HEPH 或 CDX-CODE
  │      ├─ 深度依赖 codebase 上下文 → CDX-CODE（Codex CLI + gpt-codex-5.3）
  │      └─ 深度依赖外部领域知识 / 多步推理 → OOSO-HEPH（Deep Agent = gpt-5.3-codex）
  └─ 否 → 进入问题 5

问题 5：这个任务是否是长周期异步 / 治理库分析 / 不动工程仓库代码？
  ├─ 是 → 路由到新 CDX-AIFL 式背景任务（Codex CLI nohup）
  └─ 否 → 升级给 CTRL 重新评估范围（任务划分可能有问题）

2A.2 Cursor Review Gate（强制闭环）

每个由 L3 Coding 主力（CDX-* / OOSO-*）完成的 sub-packet，在 push 到 integration 分支前必须通过 CUR-REV review gate：

Gate 检查项	由 CUR-REV 负责
acceptance criteria 全部满足（按 sub-packet frontmatter）	是
handoff anchor 已写入治理库且 schema 合规	是
共享文件 diff 在所有权矩阵内 / 未越界	是
边界硬约束未被破坏（订单 / 仓位 / 私钥 / 凭证字段未渲染 / 未持久化）	是
budget compliance（context_budget actual vs estimated 偏差 ≤ 30%）	是
任何 forbidden_execution_fields 未泄露到 API / 前端 / telemetry	是
测试覆盖（pytest / lint / type）通过	CUR-REV 监督，但执行可委托给 OOSO-SISY

Review 失败的处理：CUR-REV 写一份 review-finding anchor（handoff-anchors/<packet-id>.review-finding-<N>.yaml），列明具体缺陷 → CTRL 决定 reroute（同 agent 重做 / 切换 agent / 升级到 CUR-REV 自己接手）。

2A.3 测试职责分配矩阵

按用户指示"测试以及其他职责根据需求和场景由合适的 agents 承担"，本节固化默认路由（可按需覆盖）：

测试类型	默认承担 Agent	替代承担	备注
单元测试用例填充（标准化路径）	OOSO-SISY	CDX-MAIN	量大场景必走 SISY
边界 / 安全 / 隐私单元测试	CUR-REV 设计 + CDX-MAIN 写代码	OOSO-HEPH	设计必须 CUR-REV，禁止 L3 单独决定边界测试范围
集成测试 / SSE event 流测试	CDX-MAIN	OOSO-ATLAS	跨模块 → 优先 CDX-MAIN
性能 / 压力 / 长流测试	OOSO-HEPH	CDX-CODE	深度任务
Evaluation case 编写（V1 6 个核心 case）	CUR-REV 设计 + OOSO-ATLAS / CDX-MAIN 实施	—	acceptance criteria 设计权在 CUR-REV
Evaluation runner 实施（field-level diff）	CDX-CODE	OOSO-HEPH	coding 深度场景
Boundary Guard 单元测试	CUR-REV 亲自写或重审	—	红线相关，禁止单独委托 L3
Frontend lint guardrails 实施	CDX-MAIN + OOSO-SISY（批量加 rule）	—	rule 设计 CUR-REV，rule 实施 L3
Trial 期 e2e smoke 脚本	OOSO-ATLAS	CDX-MAIN	标准化执行
Privacy / Compliance audit script	CUR-REV 设计 + 任意 L3 实施	—	审计逻辑必须 CUR-REV 看过

2A.4 「其他职责」路由建议

职责	默认承担
治理库设计文档撰写（如本轮 B-1~B-7）	CUR-REV（文档为复杂任务）
治理库设计文档批量修订 / sync（如 P1-E 14 个 sub-packet must_read 同步）	OOSO-SISY 或 CDX-MAIN，CUR-REV review
跨 stack handoff anchor 串联	CTRL + CUR-REV
Release notes / changelog 起草	CDX-MAIN，CUR-REV review
Skill review Phase 1 self-audit（V1）	OOSO-ATLAS 按 plan 执行 + CUR-REV 抽查
Skill review Phase 2 external expert	CTRL 主导（人工）；AI 仅生成材料
Trial 期日报 digest（cost / obs）	OOSO-SISY（标准化）或 CDX-MAIN
Trial 期 incident triage	CUR-REV（复杂上下文）
紧急 hotfix（trial 期出 boundary 泄露）	CUR-REV 亲自；如 coding 量大委托 OOSO-HEPH

2A.5 不允许的路由（硬约束）

禁止把 V1 边界 / 隐私 / 安全相关 sub-packet 单独委托给 L3（必须 CUR-REV 设计或 review）；
禁止让 CDX-AIFL（背景任务）参与工程仓库代码；
禁止同一 sub-packet 同时由 CDX-MAIN + OOSO-ATLAS 并行（避免重复劳动；如需 race，CTRL 必须明确 race 决策）；
禁止任何 L3 agent 直接合并 PR 到 main（必须经 CTRL）；
禁止任何 L3 agent 自行修改 v1-engineering-kickoff-decisions.md 正文决策（升级到 CTRL）。

3. Worktree Configuration

本节由 2026-05-16 多 Agent 分工修订替换 V0 版：旧版 6 个 finclaw-agent-{A..F} worktree 布局已废弃。新版以 「stack 隔离 + 任务路由」 为核心：worktree 数量少而精，按 stack 与任务并行度切分。

3.1 工程仓库 worktree 布局（待新工程仓库初始化后）

/Users/mlabs/Programs/CurvatureLabs/finclaw/              ← main 分支（CTRL 合并目标；仅 CTRL 写）
/Users/mlabs/Programs/CurvatureLabs/finclaw-review/       ← CUR-REV 主 worktree（PR review / 复杂 spike / hotfix）
/Users/mlabs/Programs/CurvatureLabs/finclaw-codex-main/   ← CDX-MAIN worktree（量大常规 sub-packet）
/Users/mlabs/Programs/CurvatureLabs/finclaw-codex-deep/   ← CDX-CODE worktree（深度 coding；与 main 隔离避免互锁）
/Users/mlabs/Programs/CurvatureLabs/finclaw-ooso-deep/    ← OOSO-HEPH worktree（深度 / refactor）
/Users/mlabs/Programs/CurvatureLabs/finclaw-ooso-exec/    ← OOSO-ATLAS worktree（plan 标准化执行）
/Users/mlabs/Programs/CurvatureLabs/finclaw-ooso-batch/   ← OOSO-SISY worktree（量大批量任务）

说明：

不为每个 sub-packet 单独开 worktree；同一 agent 在自己的 worktree 内串行执行多个 sub-packet（context 切换时手动 git stash + git checkout）。
OOSO-PROM（plan builder）通常不需要独占 worktree；它产出的 plan 是 markdown，可在治理库写，由 CDX-MAIN / OOSO-ATLAS 读取后在自己的 worktree 执行。
紧急情况下，CTRL 可临时为某 sub-packet 开 finclaw-spike-<name>/ 短期 worktree，完成后 git worktree remove。

3.2 Worktree 启动命令模板

# 在新工程仓库 main 分支初始化后执行
cd /Users/mlabs/Programs/CurvatureLabs/finclaw
git worktree add ../finclaw-review        review/integration
git worktree add ../finclaw-codex-main    feature/codex-main
git worktree add ../finclaw-codex-deep    feature/codex-deep
git worktree add ../finclaw-ooso-deep     feature/ooso-deep
git worktree add ../finclaw-ooso-exec     feature/ooso-exec
git worktree add ../finclaw-ooso-batch    feature/ooso-batch

分支命名约定：

feature/<stack-role> —— 各 L3 agent 的工作主分支（长期存在；每个 sub-packet 完成后在分支上做 commit + push，CUR-REV review 通过后合入 integration）；
review/integration —— CUR-REV 主 review 分支（接收所有 feature 分支的 merge 请求；CUR-REV review 通过后由 CTRL 合入 main）；
spike/<name> —— 短期实验 / hotfix 分支（任意 agent 可创建；完成或丢弃后立即清理）。

3.3 文件所有权矩阵

V0 版"业务包 ↔ Cursor agent"绑定已废弃；V1 改为**「业务包 ↔ 默认承担 agent + 审计 agent」** 双轴矩阵：

Package	默认承担（首次实施）	审计 / 红线守门	共享文件协调说明
`server/agent/runtime.py` / `boundary_guard.py`	OOSO-HEPH 或 CDX-CODE（核心 logic）	CUR-REV（每次改动必 review）	红线相关，禁止 L3 独立决定
`server/agent/models.py`	CDX-MAIN	CUR-REV	任何字段变更需在 handoff anchor 声明，避免 schema drift
`server/agent/context_engine.py` / `skill_manager.py` / `object_writer.py`	CDX-MAIN	CUR-REV	任意 L3 可改，但 `_ADVISOR_PROFILES` / `_ROUTE_INSTRUCTIONS` 变更需 CUR-REV
`server/tools/`	CDX-MAIN（常规工具）/ OOSO-HEPH（复杂工具）	CUR-REV	MCP 接入 / 凭证处理走 CUR-REV
`server/api/`	CDX-MAIN（routes / schemas）	CUR-REV	API contract 变更必须 review；前端协议同步走 handoff anchor
`server/skills/*/SKILL.md`	OOSO-ATLAS 按 plan 实施	CUR-REV 评 acceptance	边界条款（pre_execution / sensitive_rejection / evidence_audit）必须 CUR-REV
`web/src/`	CDX-MAIN（常规组件）/ OOSO-HEPH（复杂交互如 Refresh Diff）	CUR-REV	frontend lint guardrails 由 CUR-REV 设计
`server/tests/` 单元测试用例填充	OOSO-SISY 或 CDX-MAIN	CUR-REV 抽查	边界 / 隐私测试必须 CUR-REV 设计
`server/tests/test_boundary_guard.py` 等红线测试	CUR-REV 亲自写或重审	CTRL	不允许 L3 独立修改红线测试范围
`evaluation/` cases + runner	CDX-CODE（runner）/ CUR-REV 设计（cases）	CUR-REV	acceptance criteria 设计权在 CUR-REV
`config/`	CTRL + CUR-REV	CTRL	任何 provider / pricing / budget cap 变更必须 CTRL sign-off
`.github/workflows/` / CI 配置	CDX-MAIN	CUR-REV	任意 L3 可改 CI，但 release / publish workflow 必须 CTRL

共享文件冲突规则：

变更前在 hand-off anchor 中声明意图 → handoff-anchor key_decisions_locked 字段写明"本 packet 将修改 path/to/file"；
多个 sub-packet 同时声明同一文件 → CTRL 在 task routing 决策时强制串行（不允许并行修改 models.py）；
同行并发冲突 → CTRL 裁决（见 v1-multi-agent-execution-protocol.md §5.1）；
红线相关文件（boundary_guard / models.py 字段定义 / forbidden_execution_fields）改动必须 CUR-REV gate（即使是 L3 实施，最终落仓必须 CUR-REV 显式 approve）。

4. Phase-by-Phase Parallel Plan

本节由 2026-05-16 多 Agent 分工修订替换 V0 版：所有 sub-packet 重新按 §2 Capability Matrix + §2A Decision Tree 分配；每个 L3 完成的 sub-packet 必须经 CUR-REV review gate（§2A.2）。

4.1 阶段 1：核心架构设计（已完成）

Step	完成 Agent	Sub-packet	状态
1.1	CUR-REV	起草 `v1-tech-stack-and-architecture-design.md`（B-1）	done（Wave 1，2026-05-16）
1.2	CUR-REV	起草 `v1-data-and-persistence-design.md`（B-2）	done（Wave 1）
1.3	CUR-REV	起草 `v1-api-contract-design.md`（B-3）	done（Wave 1）

为什么由 CUR-REV 完成：架构 / 数据 / API 契约是 L2 复杂任务，涉及红线 / 隐私 / 跨包接口锁定，不可委托给 L3。

4.2 阶段 2：辅助设计文档（已完成）

Track	完成 Agent	Sub-packet	状态
Track A	CUR-REV	`v1-ui-prototype-and-design-system.md`（B-4）	done（Wave 2）
Track B	CUR-REV	`v1-observability-and-telemetry-design.md`（B-5）	done（Wave 2）
Track C	CUR-REV	`v1-memory-and-personalization-design.md`（B-6）	done（Wave 2）
Track D	CUR-REV	`v1-cost-and-token-budget-design.md`（B-7）	done（Wave 2）

完成证据：handoff-anchors/v1-eng-design-wave1.yaml + wave2.yaml + v1-p1-residual-cleanup.yaml（review 余债清理）。

4.3 阶段 3：新工程仓库骨架（单线，约 1-2 天）

Step	默认 Agent	审计	任务	备注
3.1	CDX-CODE 或 OOSO-HEPH	CUR-REV	在 `/Users/mlabs/Programs/CurvatureLabs/finclaw/` 初始化新仓库（git init + 项目骨架 + 依赖 + Makefile + CI 配置）	CUR-REV 必须 review 骨架是否能跑 smoke test
3.2	CDX-CODE	CUR-REV	按 D-10.a 选择性迁移清单逐组件 review-then-migrate	每个组件迁移完成必须 CUR-REV check
3.3	CDX-CODE	CUR-REV	重写 `llm_client` 支持 GPT-5.5 + Kimi K2.6（OpenAI-compatible adapter）	LLM Provider Layer 是边界相关，CUR-REV 强 review
3.4	CTRL	—	验证骨架可启动 + 测试通过 → 在 main 分支打 tag `v1-skeleton-ready`	CTRL 亲自验证
3.5	CTRL	—	按 §3.2 命令初始化 6 个 worktree（review / codex-main / codex-deep / ooso-deep / ooso-exec / ooso-batch）	CTRL 亲自执行

为什么主要由 CDX-CODE 承担：阶段 3 是深度 coding 任务（新仓库 bootstrap + 跨语言迁移 + provider 抽象层重写），适合 gpt-codex-5.3。OOSO-HEPH 是替代方案（如 CDX-CODE 资源紧张时切换）。

4.4 阶段 4：V1 工程实现（多 stack worktree 并行，约 5-10 天）

参考 v1-engineering-kickoff-decisions.md D-10.a 选择性迁移 + 15 个 sub-packet。

4.4.1 Sub-Packet 分配（按 §2A Decision Tree）

Sub-Packet	默认承担（L3）	红线 / 复杂度	Review Gate	依赖
`v1-eng-impl-sub-1-profile-consent`	CDX-MAIN（常规 endpoint + persistence）	隐私 + 撤回联动跨 B-2/B-6	CUR-REV 设计 + review	阶段 3 完成
`v1-eng-impl-sub-2-sensitive-input-handling`	OOSO-HEPH 或 CUR-REV 亲自	红线最高敏感度（凭证 / 私钥 / boundary guard 联动）	CUR-REV 全程参与	sub-1 完成（共享 models.py）
`v1-eng-impl-sub-3-training-asset-candidate`	CDX-MAIN	中（候选治理元数据 + retention）	CUR-REV review	sub-1 完成
`v1-eng-impl-sub-4-refresh-diff-view`	OOSO-HEPH（复杂跨包 UI / diff 算法）	中（跨 B-2/B-3/B-4/B-5/B-6 五份设计）	CUR-REV review	sub-1 完成
`v1-eng-impl-sub-5-save-thread-sheet`	CDX-MAIN（常规 UI 组件 + 模型联动）	中	CUR-REV review	sub-4 完成
`v1-eng-impl-sub-6-feedback-review-queue`	CDX-MAIN（前后端常规链路） + OOSO-ATLAS（标准化执行 plan）	中（Persona Drift Log emit 入口）	CUR-REV review	sub-5 完成
`v1-eng-impl-sub-7-skill-naming-and-tests`	OOSO-ATLAS（按 Route Ontology §4A plan 执行）+ OOSO-SISY（用例批量填充）	中（命名跨域规则 + V1 6 case 覆盖）	CUR-REV 设计 cases	阶段 3 完成
`v1-eng-impl-sub-8-deprecate-old-docs`	OOSO-SISY（批量 deprecation 标记）	低	CUR-REV 抽查	阶段 3 完成
`v1-cs-instr-sub-1-schema-design`	OOSO-PROM 出 plan + CDX-MAIN 实施	中（CS schema + 隐私守门）	CUR-REV review	阶段 2 Track B 完成
`v1-cs-instr-sub-2-engineering-impl`	CDX-MAIN（后端 emit）+ CDX-MAIN（前端 hook）	中（cost_telemetry forward 4 个 cs-event）	CUR-REV review	cs-sub-1 完成
`v1-cs-instr-sub-3-privacy-review`	CUR-REV 设计 + 任意 L3 实施	高（隐私守门 + 撤回联动 + Trace retention）	CUR-REV 亲自终审	阶段 4 主体完成
`v1-trial-sub-1-cohort-prep`	CTRL 主导（人工招募 Labs 内测 3 人）	低	CTRL 亲自	cs-sub-3 完成
`v1-trial-sub-2-trial-execution`	CTRL + OOSO-SISY（标准化 daily digest）	中	CUR-REV review digest 模板	trial-sub-1 完成
`v1-skills-review-sub-1-phase1-ai-self-audit`	OOSO-ATLAS（按 Skills plan 执行）	中	CUR-REV 抽查	阶段 3 完成 + 已授权
`v1-skills-review-sub-2-phase2-external-expert-review`	CTRL 主导（人工 + 外部专家）	中	CTRL 亲自	trial 跑过 + 6-12 份样本输出 + 项目发起人确认外部路径

4.4.2 并行图（按 stack）

阶段 3 完成 (v1-skeleton-ready tag)
    │
    ├─── 红线 / 复杂 sub-packet（CUR-REV 设计或亲自）
    │       ├─ sub-2 sensitive-input-handling   (CUR-REV + OOSO-HEPH)
    │       └─ cs-sub-3 privacy-review          (CUR-REV 设计 + L3 实施 + CUR-REV 终审)
    │
    ├─── CDX-MAIN（量大常规 sub-packet 主力）
    │       ├─ sub-1 profile-consent     →  sub-3 training-asset
    │       ├─ sub-5 save-thread-sheet (依赖 sub-4)
    │       ├─ sub-6 feedback-review-queue (依赖 sub-5; 与 OOSO-ATLAS 协作)
    │       └─ cs-sub-1 + cs-sub-2 (依赖 OOSO-PROM 的 plan)
    │
    ├─── CDX-CODE（深度任务）
    │       └─ 阶段 3 骨架 (主要承担) + 性能 / refactor spike (按需)
    │
    ├─── OOSO-PROM → OOSO-ATLAS（plan + 执行配对）
    │       ├─ PROM 出 cs-sub-1 schema plan → ATLAS 协助实施
    │       ├─ PROM 出 sub-7 skill naming plan → ATLAS 执行 + SISY 填用例
    │       └─ skills-review-sub-1 (ATLAS 按 plan)
    │
    ├─── OOSO-HEPH（深度复杂）
    │       ├─ sub-2 sensitive-input (与 CUR-REV)
    │       └─ sub-4 refresh-diff-view (跨 5 份设计)
    │
    ├─── OOSO-SISY（量大批量）
    │       ├─ sub-7 用例批量填充
    │       ├─ sub-8 deprecate-old-docs
    │       └─ trial-sub-2 daily digest 模板
    │
    ├─── CUR-REV（review gate；每个 L3 sub-packet 完成必经）
    │       └─ review-finding anchor → reroute 决策
    │
    └─── CDX-AIFL（背景，已运行）
            └─ aifinlab Root Skills 5 batch → 治理库 (与工程仓库物理隔离)

4.4.3 关键同步点

每个 L3 sub-packet 完成时：
1. L3 写 handoff anchor 到治理库；
2. L3 push 自己的 feature 分支（不是 integration）；
3. CUR-REV 启动 review gate（§2A.2）；通过 → L3 把分支 merge 到 review/integration；不通过 → CUR-REV 写 review-finding anchor，CTRL 决定 reroute；
4. CTRL 触发 review/integration 的 smoke test；
5. CTRL 把 review/integration 合入 main。
每天结束：CTRL 主导一次 integration checkpoint（确认所有 feature → review → main 链路通畅）。
阶段 4 完成判据：所有 8 个 eng-impl sub-packet + 3 个 cs-instr sub-packet + skills-review-sub-1 全部 done 且 CUR-REV 已 sign-off；evaluation runner 跑通 6 个 V1 case。

4.4.4 跨 stack handoff 规则

跨 stack 接力点（如 OOSO-PROM 出 plan → CDX-MAIN 实施）必须通过治理库 handoff anchor 传递，不通过 chat history 或共享 chat session：

OOSO-PROM 完成 plan
   ↓ 写 handoff-anchors/v1-eng-impl-sub-X-plan.yaml
   ↓ produced_artifacts: [design/v1/v1-eng-impl-sub-X-plan-detail.md]
   ↓ next_packets_unblocked: [v1-eng-impl-sub-X-execution]
       ↓
CTRL 看到 next_packets_unblocked → 路由 CDX-MAIN
       ↓
CDX-MAIN 新会话启动 → 读 plan anchor + plan detail md + sub-packet must_read
   ↓ 执行
   ↓ 写 handoff-anchors/v1-eng-impl-sub-X.yaml（最终 anchor）
   ↓ 触发 CUR-REV gate

跨 stack 接力点禁止：

用 chat history 传递关键决策（必须落 anchor）；
跨 stack 共享中间 in-memory 状态（不存在的事，禁止假设）；
让 PROM 与 ATLAS 在同一 stack 的同一会话内"串通"（违反 v1-multi-agent-execution-protocol.md §4.1 每次新会话独立载入的规则）。

4.5 阶段 5：评测与试运营准备（约 2-3 天）

Sub-Packet	默认承担	触发条件
`v1-cs-instr-sub-3-privacy-review`	CUR-REV 设计 + 任意 L3 实施 + CUR-REV 终审	阶段 4 完成
`v1-trial-sub-1-cohort-prep`	CTRL 主导（人工招募 Labs 3 人）	cs-instr-sub-3 完成
`v1-trial-sub-2-trial-execution`	CTRL 主导 + OOSO-SISY（daily digest 模板）+ CUR-REV（incident triage）	trial-sub-1 完成
`v1-skills-review-sub-2-phase2-external-expert-review`	CTRL 主导（人工 + 外部专家）	trial 跑过 + 项目发起人确认 `evaluation/finclaw/reports/*` 路径

阶段 5 的多数 sub-packet 是 CTRL 主导（涉及人工决策、用户对话、外部专家协调）；AI Agent 仅做支持（按 §2A.3-§2A.4 路由）。

4.6 横向并行：CDX-AIFL（aifinlab Root Skills）

触发	持续
已启动（PID 10466，2026-05-16 09:56）	5 batch；预计 1-2 天异步完成

完全独立于工程仓库；产出全部写入治理库 reference-experience/aifinlab-root-skills-taxonomy/，不参与 §4.4 主线。

5. Hand-off Flow

5.1 单 Sub-Packet 闭环

Agent 启动
  ↓ 加载: must_read sections (按 sub-packet frontmatter)
  ↓ 加载: 直接前置 sub-packet 的 hand-off anchor (≤ 5K)
  ↓
写出 started anchor:                                    ← 新增：立即写 <packet-id>.started.yaml
  └─ handoff-anchors/<packet-id>.started.yaml           （completion_status: started, progress: 0）
  ↓                                                      → Dashboard 即时感知到任务进入 in-progress
执行 sub-packet
  ↓ (≥50% 进度时写 partial anchor，见 v1-handoff-anchor-template.md §2A)
  ↓ 验证 acceptance_criteria
  ↓
写出:
  ├─ 工程仓库代码 / 测试 → push feature branch
  ├─ hand-off anchor YAML → 治理库 handoff-anchors/
  └─ handoff-anchors/README.md 索引追加一行
  ↓
通知 Controller (人工或 next_packets_unblocked 列表)

5.2 跨 Agent 接力

Agent-A 完成 sub-1
  → hand-off anchor 写入治理库
  → next_packets_unblocked: [sub-2, sub-3]
       ↓
Controller 看到 next_packets_unblocked
  → 分配 sub-2 给 Agent-A、sub-3 给 Agent-A（或并行给其他 agent）
       ↓
Agent-A（新会话）启动 sub-2
  → 加载 sub-2.must_read + sub-1.handoff-anchor
  → 执行
  → 写新 anchor

关键：每次新会话从治理库 anchor + must_read 重新载入，不继承上次会话的 chat history。这是协议 §4.1 的强制要求。

6. Launch Commands

本节由 2026-05-16 多 Agent 分工修订替换 V0 版：V0 默认不启用 OOSO 已废弃；V1 OOSO 4 角色是 coding 主力的一部分。

6.1 Cursor as CUR-REV / CTRL 启动（项目发起人手动驱动）

CTRL 与 CUR-REV 共用 Cursor 入口，按 worktree 区分：

角色	Worktree	启动方式
CTRL	`/Users/mlabs/Programs/CurvatureLabs/finclaw/`（main）	普通 Cursor 窗口；用于决策 / 合并 / 跨 stack 调度
CUR-REV	`/Users/mlabs/Programs/CurvatureLabs/finclaw-review/`（review/integration）	普通 Cursor 窗口；用于复杂 sub-packet + review gate

CUR-REV 启动 prompt 模板（review gate 用）：

你是 V1 CUR-REV（Cursor + Opus 4.6/4.7）执行 review gate。
被 review 的 sub-packet：[sub-packet 路径]
被 review 的 hand-off anchor：[anchor 路径]
被 review 的 feature 分支：[分支名]

请按 v1-multi-agent-coordination-plan.md §2A.2 review gate 7 项检查：
1. acceptance_criteria 全部满足
2. handoff anchor schema 合规
3. 共享文件 diff 在所有权矩阵内
4. 边界硬约束未破坏（订单/仓位/私钥/凭证字段）
5. budget compliance（actual vs estimated 偏差 ≤ 30%）
6. forbidden_execution_fields 未泄露到 API / 前端 / telemetry
7. 测试 / lint / type check 通过

通过 → 把 feature 分支 merge 到 review/integration 并在 anchor 中标 review_approved。
不通过 → 写 handoff-anchors/<packet-id>.review-finding-<N>.yaml 列明缺陷，
然后通知 CTRL 决定 reroute（同 agent 重做 / 切换 agent / 你自己接手）。

CUR-REV 启动 prompt 模板（复杂 sub-packet 亲自实施）：

你是 V1 CUR-REV（Cursor + Opus 4.6/4.7）。本次为复杂 sub-packet 亲自实施。
本次任务包：[sub-packet 路径]
前置 hand-off anchor：[anchor 路径]（如有）

按 sub-packet frontmatter `context_budget.must_read` 加载文档（不要全读 reference_only）。
完成 acceptance_criteria 后必须产出 hand-off anchor 到 [声明的 handoff_anchor_path]。
遵守 v1-multi-agent-execution-protocol.md §10 反模式禁止项 +
v1-handoff-anchor-template.md §2A 抗中断 partial anchor 协议（≥50% 进度强制写 partial）。

6.2 Codex 启动模板（CDX-MAIN / CDX-CODE，主力 coding）

从 Cursor 内部调度走 MCP codex.*（首选）；fallback 走 Shell codex exec。

MCP 路径（首选）：在 Cursor 对话中直接调用 codex.run MCP 工具，参数包括 working_directory、model（gpt-5.5 / gpt-codex-5.3）、prompt。详见 personal-domain-admin docs/09-cross-agent-dispatch.md。

Shell fallback 模板（CDX-MAIN 同步执行）：

codex exec \
  --sandbox workspace-write \
  --skip-git-repo-check \
  --cd /Users/mlabs/Programs/CurvatureLabs/finclaw-codex-main \
  --model gpt-5.5 \
  "你是 V1 CDX-MAIN（Codex + GPT-5.5）。
   本次任务包：[sub-packet 路径]
   前置 hand-off anchor：[anchor 路径]（如有）

   按 sub-packet frontmatter must_read 加载文档（不要全读 reference_only）。
   完成 acceptance_criteria 后必须产出 hand-off anchor 到 [声明的 handoff_anchor_path]。
   完成后 push feature/codex-main 分支，但**不要**自行合入 review/integration。
   遵守 v1-multi-agent-execution-protocol.md §10 反模式禁止项 +
   v1-handoff-anchor-template.md §2A 抗中断协议。"

Shell fallback 模板（CDX-CODE 深度任务）：把 --model gpt-5.5 改为 --model gpt-codex-5.3，cwd 改为 finclaw-codex-deep，prompt 中明确"深度 coding 任务，可使用 codebase-aware 工具进行跨文件分析"。

长后台任务模板（如 CDX-AIFL aifinlab 异步分析）：参考已启动的 PID 10466 nohup 模式：

nohup codex exec \
  --sandbox workspace-write \
  --skip-git-repo-check \
  --cd /Users/mlabs/Programs/Labs-FinTecAI \
  --model gpt-5.5 \
  "[详细 prompt，引用治理库执行计划文档]" \
  > ~/Labs-FinTecAI-logs/codex-<task-name>/run-$(date +%Y%m%d-%H%M%S).log 2>&1 &

6.3 OOSO 4 角色启动模板

OOSO 不提供 MCP（详见 global.mdc Cross-agent dispatch），所有 OOSO 调度走 Shell + oh-my-opencode run --json。

核心模板（按 §2.2 4 角色绑定填 --role + cwd）：

oh-my-opencode run \
  --json \
  --role <prometheus | atlas | hephaestus | sisyphus> \
  --cwd <对应 worktree> \
  --prompt "[标准 prompt + tools-contract + verification block]"

按 ~/Programs/opencode-integration/OOSO_INTEGRATION_GUIDE.md 中的 prompt + tools-contract + verification 三段式模板填写 prompt。

6.3.1 OOSO-PROM（Prometheus = Plan Builder = gpt-5.5）

oh-my-opencode run --json \
  --role prometheus \
  --cwd /Users/mlabs/Programs/CurvatureLabs/finclaw-review \
  --prompt "你是 V1 OOSO-PROM。本次任务：为 [sub-packet 路径] 出技术方案 plan。
            按 sub-packet frontmatter must_read 加载文档。
            产出物：design/v1/v1-eng-impl-sub-X-plan-detail.md + handoff-anchors/v1-eng-impl-sub-X-plan.yaml。
            不要写代码；只出 plan。
            禁止改动 v1-engineering-kickoff-decisions.md 正文决策。"

注：PROM 的 cwd 通常用 finclaw-review（与 CUR-REV 同 worktree，因 PROM 产出物落治理库而非工程仓库）。

6.3.2 OOSO-ATLAS（Atlas = Plan Executor = Kimi K2.6）

oh-my-opencode run --json \
  --role atlas \
  --cwd /Users/mlabs/Programs/CurvatureLabs/finclaw-ooso-exec \
  --prompt "你是 V1 OOSO-ATLAS。本次任务：按 [PROM plan 路径] 实施 sub-packet [路径]。
            前置 PROM plan anchor：[anchor 路径]
            按 sub-packet must_read + plan 详细规格执行。
            完成后产出 hand-off anchor + push feature/ooso-exec 分支。
            **不要**修改 plan（如发现 plan 有问题，写 review-finding 而非自行偏离）。"

6.3.3 OOSO-HEPH（Hephaestus = Deep Agent = gpt-5.3-codex）

oh-my-opencode run --json \
  --role hephaestus \
  --cwd /Users/mlabs/Programs/CurvatureLabs/finclaw-ooso-deep \
  --prompt "你是 V1 OOSO-HEPH（深度 coding agent）。本次任务：[sub-packet 路径]。
            前置 hand-off anchor：[anchor 路径]（如有）
            本任务被标为深度（复杂算法 / 大型 refactor / 跨多模块 migration）。
            按 must_read 加载；可使用工具做跨文件深度分析。
            完成后产出 hand-off anchor + push feature/ooso-deep 分支。
            完成度达 50% 时强制写一次 partial anchor（v1-handoff-anchor-template.md §2A）。
            红线相关变更**禁止**单独决定，必须先升级到 CUR-REV。"

6.3.4 OOSO-SISY（Sisyphus = Ultraworker = Kimi K2.6）

oh-my-opencode run --json \
  --role sisyphus \
  --cwd /Users/mlabs/Programs/CurvatureLabs/finclaw-ooso-batch \
  --prompt "你是 V1 OOSO-SISY（量大批量 worker）。本次任务：[标准化批量任务清单]。
            示例任务类型：14 个 sub-packet frontmatter 同步 / 50+ 文件 docstring 补全 / 一致性扫描 / 测试用例批量填充。
            每完成 5 个文件强制写一次 partial anchor（v1-handoff-anchor-template.md §2A.1 多文件批量门）。
            完成后产出最终 hand-off anchor + push feature/ooso-batch 分支。
            禁止改动已声明 out-of-scope 的文件。"

6.4 监控命令

6.4.1 Codex 后台任务监控

tail -f ~/Labs-FinTecAI-logs/codex-aifinlab-rootskills/run-*.log
ps -p <PID>
ls -lt /Users/mlabs/Programs/Labs-FinTecAI/projects/finclaw/reference-experience/aifinlab-root-skills-taxonomy/

6.4.2 OOSO 任务监控

# OOSO 任务日志（按 OOSO 默认日志位置；见 OOSO_INTEGRATION_GUIDE.md）
tail -f ~/opencode-logs/ooso-<role>-<task-id>/run.log

# 检查 OOSO 任务状态
oh-my-opencode status --json --role <role> --task-id <id>

6.4.3 治理库 handoff anchor 落地监控

# 列出最近 24h 内新增的 handoff anchor
find /Users/mlabs/Programs/Labs-FinTecAI/projects/finclaw/handoff-anchors -name "*.yaml" -mtime -1 -ls

# 看本周 review gate 通过率
grep -l "review_approved: true" /Users/mlabs/Programs/Labs-FinTecAI/projects/finclaw/handoff-anchors/*.yaml | wc -l

6.4.4 工程仓库分支状态监控

cd /Users/mlabs/Programs/CurvatureLabs/finclaw
git branch -a --sort=-committerdate | head -20      # 最近活跃分支
git log --all --oneline --graph --decorate -20      # 跨分支提交关系

7. Monitoring and Sync Points

7.1 Daily Sync（项目发起人主导，约 15 分钟）

每天结束前检查：

治理库 handoff-anchors/ 当日新增 anchor 数量；
所有 feature branch 状态（已 push 未合？已合并？rebase 冲突？）；
集成分支跑测试是否通过；
当日 Codex 后台日志是否有错误；
决策记录 / 风险登记是否需要更新。

7.2 Milestone Sync（M-B5、M-B10 等关键节点）

Milestone	检查项
M-B1 工程仓库骨架就绪	所有 worktree 可创建；smoke test 通过
M-B5 工程主体完成	8 个 eng-impl sub-packet 全部 done
M-B10 Trial-start review	cs-instr + skills-review-sub-1 + privacy-review 全部 done；可启动 trial

7.3 自动化（可选 P2 增项）

Hand-off anchor 校验脚本（验证 YAML schema + budget compliance）；
治理库 anchor 索引页自动生成；
工程仓库每个 sub-packet PR 自动跑 lint + test。

8. Failure Recovery

8.1 Sub-Packet 内失败

失败模式	恢复路径
Context budget 超限 / 输出质量下降	中断 → 写 partial anchor → 切片更细 → 新 sub-packet 接手
Acceptance criteria 未通过	状态 partial → 写入 anchor 的 open_questions → 下一个 sub-packet 处理
工程测试失败	feature branch 自行修复；不 push 到 integration 直到通过
共享文件冲突	Agent 立即停止；通知 Controller 裁决；裁决结果写入治理库决策记录

8.2 Agent 失败 / 卡住

情况	恢复
Agent 长时间无产出	CTRL 复查 must_read 是否合理；如 too much，切片后重启
Agent 反复跑错	检查 hand-off anchor 与 sub-packet must_read 是否一致；如冲突，更新一方
Codex 后台任务异常退出	查 log → 必要时重启（保留已完成 batch 的产出，不重头跑）
OOSO 任务超时 / hang	OOSO `status --json` 检查；如 hang 超 30 分钟 kill + 重启；多次 hang 升级 CTRL 切换到 Codex
Subagent 因 TLS / PING 中断	按 v1-handoff-anchor-template.md §2A.6 failure mode：CTRL 读最后一个 partial anchor → 验证已落盘文件 → 由后继 Agent 续作
CUR-REV 自己 hang	CTRL 接手 review gate（不允许跳过 review gate；不允许 L3 自批准）

8.3 Cross-Agent 冲突

冲突类型	解决
同一文件同行修改	CTRL 裁决；裁决后被否定方需放弃自己版本
接口契约不一致	走 API contract 修订 PR；所有相关 Agent 必须基于合并后版本
决策漂移（实际产出与 D-XX 冲突）	该 sub-packet 立即 blocked；升级到项目发起人
L3 自行跳过 CUR-REV gate（试图直接 push 到 review/integration）	CTRL 立即 revert + 在该 anchor `risks_or_debt` 登记 + 将该 agent 在本 sub-packet 上的下次实施改为 OOSO-HEPH（深度审计模式）

8.4 跨 stack 接力失败（重点新增）

跨 stack 接力（如 OOSO-PROM → CDX-MAIN，或 CDX-MAIN → CUR-REV gate）是 V1 协同的高风险节点。以下是失败模式与恢复路径：

失败模式	触发条件	恢复路径
PROM plan 不可执行	ATLAS / CDX-MAIN 按 plan 实施时发现 plan 缺关键决策 / 接口契约冲突	实施 agent 不自行偏离 plan；写 `handoff-anchors/<plan-id>.plan-revision-request-<N>.yaml` 列明阻塞 → CTRL 路由回 PROM 修订 plan → 修订后实施 agent 续作
CUR-REV gate 失败 → L3 反复重做	同一 sub-packet 经 3 次 review-finding 仍未通过	CTRL 强制升级 → CUR-REV 亲自接手实施或切换到 OOSO-HEPH（深度模式）
跨 stack handoff anchor 缺失	L3 完成 sub-packet 但漏写 anchor / anchor 不合规	CUR-REV gate 第 2 项检查会拦截；L3 必须补完整 anchor 后才能再次提交 review
L3 用 chat history 传递关键决策（违规）	后继 agent 启动时发现 anchor 缺少关键背景，但前一 agent 的 chat session 已结束	CTRL 升级处理：(a) 通过对话补遗（CTRL 把前一会话的关键内容补写进 anchor 的 hotfix）；(b) 后继 agent 在新 anchor 中标 `context_recovered_from_chat_history: true`，便于审计
Codex / OOSO API 故障	一段时间内 stack 不可用	临时切换路由（CDX-MAIN ↔ OOSO-ATLAS 可互换；CDX-CODE ↔ OOSO-HEPH 可互换）；切换决策记入 anchor `notes_if_overrun`
MCP 调度失败（如 codex. MCP 崩溃）*	Cursor 调度 Codex 失败	按 global.mdc fallback：用 Shell `codex exec` 替代；fallback 记入 worklog；下次 session 检查 MCP 是否恢复

8.5 Review-Finding Anchor 模板

handoff-anchors/<packet-id>.review-finding-<N>.yaml：

packet_id: <被 review 的 packet-id>
review_finding_number: <N>
reviewer: CUR-REV
reviewed_at: <ISO8601>
reviewed_anchor: handoff-anchors/<packet-id>.yaml
reviewed_branch: <feature 分支名>

gate_results:
  acceptance_criteria_met: <bool>
  handoff_anchor_compliant: <bool>
  shared_files_within_ownership: <bool>
  boundary_constraints_intact: <bool>
  budget_compliant: <bool>
  forbidden_fields_clean: <bool>
  tests_lint_typecheck_pass: <bool>

findings:
  - severity: <critical | high | medium | low>
    item: <被违反的检查项>
    description: <具体问题>
    location: <文件:行号>
    suggested_fix: <建议>

reroute_recommendation:
  - option: redo_same_agent
    rationale: <为什么这个 agent 能修>
  - option: switch_agent
    suggested_agent: <CUR-REV | OOSO-HEPH | ...>
    rationale: <为什么需要切换>
  - option: cur_rev_takeover
    rationale: <为什么 CUR-REV 必须接手>

ctrl_decision: <待 CTRL 填写>

9. Quality Gates

9.1 Sub-Packet Gate

每个 sub-packet 完成必须通过（来自协议 §7.1）：

Context budget 未超 20%
Acceptance criteria 全通过
Hand-off anchor 已写入治理库
共享文件 diff 在所有权矩阵内
Sub-packet 关联测试通过

9.2 Integration Gate（每个 milestone）

全量 pytest + lint + type check 通过
跨 agent 接口一致性通过
治理库决策记录已更新（如有）
文档/代码同步（hand-off anchor 引用的产出物真实存在）

10. Open Items

§6.4 监控脚本中的 OOSO 日志路径假定（~/opencode-logs/ooso-<role>-<task-id>/run.log）需在首次跑 OOSO 时验证；如 OOSO 实际日志位置不同，更新本节；
§7 自动化脚本待实现（handoff anchor schema validator / 治理库 anchor 索引自动生成 / 工程仓库 sub-packet PR 自动 lint + test）；
M-B5 / M-B10 的具体日期待 trial 启动时确定；
Multi-worktree 切换的 Cursor 工作流（如何快速从一个 worktree 跳到另一个）待项目发起人在执行中迭代优化；
如发现某 R1 角色（CDX-MAIN / OOSO-ATLAS 等）持续过载，考虑细分为更细的角色 / 增加并行实例；
OOSO MCP 接入：当前 OOSO 无 MCP，Shell 调度是临时路径；如 OOSO 上游推出 MCP，需在 §6.3 + global.mdc Cross-agent dispatch 同步更新优先级；
CDX-AIFL 之外的其它 L4 background task 启用决策推迟到实际需要时；
跨 stack handoff anchor 的形式化 schema 验证（§8.5 review-finding anchor 模板需要写 jsonschema）。

10A. D-13: Coordination Dashboard 决策（2026-05-16）

决策：V1 工程化进度 Dashboard 采用选项 C — 自建轻量 Dashboard。

关键定位（必须理解）

Dashboard 不是 FinClaw MVP 的一部分，不纳入 v1-eng-impl-sub-* 系列 task packet。

Dashboard 是 MVP 工程化落地的前置基础设施（Phase 0 工具）：

先交付 Dashboard（Phase 0，在 W-1 正式启动之前完成）；

再正式启动 W-1（所有 eng-impl / cs-instr / trial / skills-review sub-packet）；

全程使用 Dashboard 查看工程化全貌和各任务包执行进展，直到 MVP 完成。

Dashboard 交付是 W-1 启动的前置条件之一（与阶段 3 新仓库骨架初始化并列）。

技术选型

底盘：独立项目（不在 FinClaw 工程仓库内），位于 Labs 工具域；Vite + React + Tailwind + shadcn/ui（与 FinClaw V1 前端同栈，方便后续共享组件）+ fs watcher + 图库；

单一事实源：handoff-anchors/*.yaml + design/task-packets/*.md frontmatter + 工程仓库 git branch 状态；禁止写入 DB 镜像（只做读取 + 聚合 + 渲染）；

与 multica / paperclip / golutra 的关系：三者均不作为 Dashboard 底盘（评估见 2026-05-16 复用方案评估报告）；multica / paperclip 可继续作为"执行编排层"候选在各自演进中独立评估，不受本决策影响；golutra 因 BSL 许可 + 桌面形态不匹配出局；

部署形态：localhost:<port>，dev server 模式（vite dev + 热更新），项目发起人 / CUR-REV 浏览器打开即看；不开公网、不需 Docker、不引入外部 SaaS；

数据隔离：仅读治理库 + 工程仓库 git 元数据；不读 trial 运营数据（trial ops dashboard 由 B-5 §8 + B-7 §9 markdown digest 独立解决，不混入）；

跨项目可复用：scanner / parser / UI 组件设计为 schema-agnostic（配置化指定 anchors 目录 + frontmatter schema）；FinClaw V2 / 其他 Labs 项目只需换配置目录 + 按需扩展 schema adapter；

实施路由：CUR-REV 亲自（Phase 0 工具是跨包协同工具，需要对全局 schema 有深度理解）或 CUR-REV 设计 + CDX-MAIN 实施 + CUR-REV review。

10A.1 技术规格

位置：    /Users/mlabs/Programs/CurvatureLabs/coord-dashboard/
          （独立项目，不在 FinClaw 工程仓库 finclaw/ 内）
技术栈：  Vite 5 + React 18 + TypeScript 5.4 + Tailwind + shadcn/ui + Zustand
图库：    @dagrejs/dagre（依赖图布局）+ reactflow（交互式节点图）
fs watch：chokidar（Node.js，dev server 侧 watch → WebSocket 推 diff 到浏览器）

数据管线（全部只读，禁止写入）：
  治理库路径（.env GOVERNANCE_ROOT，默认 /Users/mlabs/Programs/Labs-FinTecAI/projects/finclaw/）
    ├── handoff-anchors/*.yaml          → parse → anchor store（in-memory）
    ├── handoff-anchors/*.partial-*.yaml → parse → partial chain store
    ├── handoff-anchors/*.review-finding-*.yaml → parse → review finding store
    ├── design/task-packets/*.md         → parse frontmatter → packet store
    └── (配置项) design/v1/v1-multi-agent-coordination-plan.md §4.4.1 → 角色分配解析

  工程仓库路径（.env ENGINEERING_ROOT，默认 /Users/mlabs/Programs/CurvatureLabs/finclaw/）
    └── git branch -a --sort=-committerdate → branch store（定时刷新，30s 间隔）

渲染模块（7 个 panel，单页 dashboard 布局）：
  ┌─────────────────────────────────────────────┐
  │  §1 PacketStatusGrid                         │  15 sub-packet × 状态 × 角色
  │      色块热力图 + 完成百分比进度条            │  pending=灰 / in-progress=蓝 / partial=橙
  │                                               │  done-await-review=紫 / done-merged=绿 / blocked=红
  ├──────────────────────┬────────────────────────┤
  │  §2 ReviewQueue      │  §3 DependencyGraph    │  左: CUR-REV 待 review 清单（按等待时间降序）
  │  等待时间 + 角色     │  reactflow DAG         │  右: next_packets_unblocked 交互式有向图
  ├──────────────────────┼────────────────────────┤
  │  §4 PartialHealth    │  §5 BudgetDrift        │  左: partial chain 健康度（>4h 标红）
  │  时间线 + 告警       │  bar chart             │  右: actual vs estimated 偏差（>30% 黄, >50% 红）
  ├──────────────────────┴────────────────────────┤
  │  §6 RiskRoster           §7 ConsistencyCheck  │  左: severity=high 聚合卡片
  │                                               │  右: 引用完整性检查（anchor 声明的 artifact 是否落地）
  └─────────────────────────────────────────────┘

启动命令：
  cd /Users/mlabs/Programs/CurvatureLabs/coord-dashboard
  pnpm install && pnpm dev   # → http://localhost:5174

配置文件 .env（切换项目即复用）：
  GOVERNANCE_ROOT=/Users/mlabs/Programs/Labs-FinTecAI/projects/finclaw
  ENGINEERING_ROOT=/Users/mlabs/Programs/CurvatureLabs/finclaw
  WATCH_INTERVAL_MS=2000
  GIT_REFRESH_INTERVAL_MS=30000

10A.2 Acceptance Criteria

pnpm dev 启动后 ≤ 3 秒可在 localhost:5174 看到 §1 全貌表 + §2 review 队列；
修改任一 handoff-anchors/*.yaml 文件后 ≤ 2 秒自动刷新视图（chokidar + WS）；
§3 依赖图正确渲染 15 个 sub-packet 的 DAG（基于 next_packets_unblocked）；
§4 标红判定：当前 UTC 时间 - partial anchor completed_at > 4h 且无更新 partial / final；
§5 budget 偏差条 > 30% 标黄、> 50% 标红（读 context_budget_actual 字段）；
§6 聚合所有 anchor 的 risks_or_debt[].severity == "high" 行；
切换 .env GOVERNANCE_ROOT 后可服务其他 Labs 项目（跨项目可复用验证）；
不读 trial 运营数据（data/events/ / data/cognition/ 等）；
不引入 Datadog / Sentry / Prometheus / Grafana 等 D-04 拒绝的 SaaS；
Dashboard 项目不在 FinClaw 工程仓库内（独立 repo / 独立目录）。

10A.3 W-1 启动前置条件清单（更新）

W-1 正式启动（第一个 eng-impl sub-packet 开始执行）必须满足以下全部条件：

#	前置条件	负责	状态
P0-1	新工程仓库 `/Users/mlabs/Programs/CurvatureLabs/finclaw/` 初始化（阶段 3 step 3.1-3.4）	CDX-CODE + CUR-REV	pending
P0-2	7 个 worktree 创建完成（阶段 3 step 3.5，见 §3.2）	CTRL	pending
P0-3	Coordination Dashboard 交付并验收（§10A.2 全部 10 条 AC 通过）	CUR-REV 或 CDX-MAIN	pending
P0-4	Dashboard 中 15 个 sub-packet 全部显示为 `pending` 状态（验证数据管线端到端打通）	CTRL 验收	pending
P0-5	跨三栈 smoke test 通过（OOSO-SISY + CDX-MAIN + CUR-REV gate 闭环至少跑通 1 个低风险任务）	CTRL	pending

11. References

v1-multi-agent-execution-protocol.md ← 规则
v1-task-packet-context-budget-schema.md
v1-handoff-anchor-template.md
v1-engineering-kickoff-decisions.md
v1-execution-plan-and-milestones.md ← 里程碑
aifinlab-root-skills-taxonomy-execution-plan.md
个人域 manual ~/Programs/CurvatureLabs/personal-domain-admin/

1. Purpose​

2. Agent Role Matrix​

2.1 角色分层（V1 锁定）​

2.2 Agent Capability Matrix（V1 锁定）​

2.3 与 personal-domain-admin 路由表的关系​

2A. Task Routing Decision Tree​

2A.1 决策树（按问题顺序回答）​

2A.2 Cursor Review Gate（强制闭环）​

2A.3 测试职责分配矩阵​

2A.4 「其他职责」路由建议​

2A.5 不允许的路由（硬约束）​

3. Worktree Configuration​

3.1 工程仓库 worktree 布局（待新工程仓库初始化后）​

3.2 Worktree 启动命令模板​

3.3 文件所有权矩阵​

4. Phase-by-Phase Parallel Plan​

4.1 阶段 1：核心架构设计（已完成）​

4.2 阶段 2：辅助设计文档（已完成）​

4.3 阶段 3：新工程仓库骨架（单线，约 1-2 天）​

4.4 阶段 4：V1 工程实现（多 stack worktree 并行，约 5-10 天）​

4.4.1 Sub-Packet 分配（按 §2A Decision Tree）​

4.4.2 并行图（按 stack）​

4.4.3 关键同步点​

4.4.4 跨 stack handoff 规则​

4.5 阶段 5：评测与试运营准备（约 2-3 天）​

4.6 横向并行：CDX-AIFL（aifinlab Root Skills）​

5. Hand-off Flow​

5.1 单 Sub-Packet 闭环​

5.2 跨 Agent 接力​

6. Launch Commands​

6.1 Cursor as CUR-REV / CTRL 启动（项目发起人手动驱动）​

6.2 Codex 启动模板（CDX-MAIN / CDX-CODE，主力 coding）​

6.3 OOSO 4 角色启动模板​

6.3.1 OOSO-PROM（Prometheus = Plan Builder = gpt-5.5）​

6.3.2 OOSO-ATLAS（Atlas = Plan Executor = Kimi K2.6）​

6.3.3 OOSO-HEPH（Hephaestus = Deep Agent = gpt-5.3-codex）​

6.3.4 OOSO-SISY（Sisyphus = Ultraworker = Kimi K2.6）​

6.4 监控命令​

6.4.1 Codex 后台任务监控​

6.4.2 OOSO 任务监控​

6.4.3 治理库 handoff anchor 落地监控​

6.4.4 工程仓库分支状态监控​

7. Monitoring and Sync Points​

7.1 Daily Sync（项目发起人主导，约 15 分钟）​

7.2 Milestone Sync（M-B5、M-B10 等关键节点）​

7.3 自动化（可选 P2 增项）​

8. Failure Recovery​

8.1 Sub-Packet 内失败​

8.2 Agent 失败 / 卡住​

8.3 Cross-Agent 冲突​

8.4 跨 stack 接力失败（重点新增）​

8.5 Review-Finding Anchor 模板​

9. Quality Gates​

9.1 Sub-Packet Gate​

9.2 Integration Gate（每个 milestone）​

10. Open Items​

10A. D-13: Coordination Dashboard 决策（2026-05-16）​

关键定位（必须理解）​

技术选型​

10A.1 技术规格​

10A.2 Acceptance Criteria​

10A.3 W-1 启动前置条件清单（更新）​

11. References​