uncaged/workflow
10
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases Wiki Activity

RFC: develop workflow + solve-issue refactor #55

New Issue
Closed
opened 2026-05-07 13:34:34 +00:00 by xiaoju · 1 comment
xiaoju commented 2026-05-07 13:34:34 +00:00
Owner
Copy Link
Copy Source

Refactor: 从 solve-issue 中拆出 develop workflow，solve-issue 作为父 workflow 通过 workflowAsAgent 调用 develop。

背景

现在 solve-issue 是一个扁平的 5-role workflow：preparer → planner → coder ⟲ → reviewer ⟲ → committer。

拆分后：

  • develop: 纯开发 workflow，从 CAS 需求出发，plan → code → review → test → commit（不 push）
  • solve-issue: 父 workflow，prepare → develop-as-agent → submit（push + PR）

develop workflow

planner → coder ⟲ → reviewer ⟲ → tester → committer
  • 输入：需求描述（从 CAS 或 prompt）
  • 新增 tester role：运行 build/test/lint 验证，通过/失败
  • committer 改为只 commit 不 push（没有 remote 假设）
  • 输出：Merkle DAG root hash（包含所有 step 信息）

tester role

type TesterMeta = {
  status: "passed" | "failed";
  details: string;  // test output summary
};

moderator 路由：

  • reviewer approved → tester
  • tester passed → committer
  • tester failed → coder（回去修）
  • reviewer rejected → coder（回去修）

solve-issue workflow（父 workflow）

preparer → developer → submitter
  • preparer：不变，找 repo、读 conventions
  • developer：workflowAsAgent("develop")，extractMode: "react"
    • 从子 workflow DAG 中提取：branch、commitSha、filesChanged、summary
  • submitter：新 role，push branch + 创建 PR
    • 用 developer 提取的信息写 PR description

developer role（父 workflow 中）

type DeveloperMeta = {
  branch: string;
  commitSha: string;
  filesChanged: string[];
  summary: string;
};

extractMode: "react" — 通过 cas_get 遍历子 workflow DAG，读 committer step 拿 branch/sha，读 coder steps 拿 filesChanged。

submitter role

type SubmitterMeta = {
  status: "submitted" | "failed";
  prUrl: string | null;
  error: string | null;
};

分阶段实施

Phase 1: tester role + develop workflow template

  • 新建 workflow-role-tester
  • 修改 committer：不 push
  • 新建 workflow-template-develop（planner → coder ⟲ → reviewer ⟲ → tester → committer）
  • 测试

Phase 2: developer role + submitter role

  • 新建 developer role（extractMode: "react"，用 workflowAsAgent("develop")）
  • 新建 workflow-role-submitter
  • 测试

Phase 3: 改造 solve-issue 为父 workflow

  • solve-issue 改为 preparer → developer → submitter
  • 移除 solve-issue 对 planner/coder/reviewer/committer 的直接依赖
  • 集成测试

Phase 4: 配置 extract provider + 端���端验证

  • 配置 workflow.yaml 的 extract provider
  • 构建 develop bundle 并注册
  • 构建 solve-issue bundle 并注册
  • 端到端跑一次

Open Questions

  1. tester 失败后回 coder，reviewer 失败也回 coder，moderator 怎么区分两种 feedback？
  2. develop workflow 的 committer 不 push，那现有 solve-issue 的 committer 是 push 的 — 要拆两个版本还是参数化？
  3. submitter 需要知道 repo 信息（remote URL）来 push/PR，这个信息从哪来？preparer 的 meta？

Refs #25, #40

Refactor: 从 solve-issue 中拆出 develop workflow，solve-issue 作为父 workflow 通过 workflowAsAgent 调用 develop。 ## 背景 现在 solve-issue 是一个扁平的 5-role workflow：preparer → planner → coder ⟲ → reviewer ⟲ → committer。 拆分后： - **develop**: 纯开发 workflow，从 CAS 需求出发，plan → code → review → test → commit（不 push） - **solve-issue**: 父 workflow，prepare → develop-as-agent → submit（push + PR） ## develop workflow ``` planner → coder ⟲ → reviewer ⟲ → tester → committer ``` - 输入：需求描述（从 CAS 或 prompt） - 新增 **tester** role：运行 build/test/lint 验证，通过/失败 - **committer** 改为只 commit 不 push（没有 remote 假设） - 输出：Merkle DAG root hash（包含所有 step 信息） ### tester role ```typescript type TesterMeta = { status: "passed" | "failed"; details: string; // test output summary }; ``` moderator 路由： - reviewer approved → tester - tester passed → committer - tester failed → coder（回去修） - reviewer rejected → coder（回去修） ## solve-issue workflow（父 workflow） ``` preparer → developer → submitter ``` - **preparer**：不变，找 repo、读 conventions - **developer**：`workflowAsAgent("develop")`，extractMode: "react" - 从子 workflow DAG 中提取：branch、commitSha、filesChanged、summary - **submitter**：新 role，push branch + 创建 PR - 用 developer 提取的信息写 PR description ### developer role（父 workflow 中） ```typescript type DeveloperMeta = { branch: string; commitSha: string; filesChanged: string[]; summary: string; }; ``` extractMode: "react" — 通过 cas_get 遍历子 workflow DAG，读 committer step 拿 branch/sha，读 coder steps 拿 filesChanged。 ### submitter role ```typescript type SubmitterMeta = { status: "submitted" | "failed"; prUrl: string | null; error: string | null; }; ``` ## 分阶段实施 ### Phase 1: tester role + develop workflow template - 新建 `workflow-role-tester` - 修改 committer：不 push - 新建 `workflow-template-develop`（planner → coder ⟲ → reviewer ⟲ → tester → committer） - 测试 ### Phase 2: developer role + submitter role - 新建 developer role（extractMode: "react"，用 workflowAsAgent("develop")） - 新建 `workflow-role-submitter` - 测试 ### Phase 3: 改造 solve-issue 为父 workflow - solve-issue 改为 preparer → developer → submitter - 移除 solve-issue 对 planner/coder/reviewer/committer 的直接依赖 - 集成测试 ### Phase 4: 配置 extract provider + 端���端验证 - 配置 workflow.yaml 的 extract provider - 构建 develop bundle 并注册 - 构建 solve-issue bundle 并注册 - 端到端跑一次 ## Open Questions 1. tester 失败后回 coder，reviewer 失败也回 coder，moderator 怎么区分两种 feedback？ 2. develop workflow 的 committer 不 push，那现有 solve-issue 的 committer 是 push 的 — 要拆两个版本还是参数化？ 3. submitter 需要知道 repo 信息（remote URL）来 push/PR，这个信息从哪来？preparer 的 meta？ Refs #25, #40
xiaoju commented 2026-05-07 13:56:28 +00:00
Author
Owner
Copy Link
Copy Source

验证结果汇总

  • ✅ Phase 1: tester role + develop workflow (#58, PR #61) — 173 tests
  • ✅ Phase 2: developer + submitter + solve-issue refactor (#59, PR #62) — 188 tests
  • ✅ Phase 3: bundle 构建 + 配置 (#60)
    • develop: WJHACJHAFH94A
    • solve-issue: D5SKZJ5QPAZPG
    • extract provider: DashScope qwen-plus

新架构

solve-issue (parent)
├── preparer
├── developer → workflowAsAgent("develop")
│   └── develop (child)
│       ├── planner
│       ├── coder ⟲
│       ├── reviewer ⟲
│       ├── tester
│       └── committer
└── submitter (push + PR)

RFC #55 完成，Close。

—— 小橘 🍊（NEKO Team）

## 验证结果汇总 - ✅ Phase 1: tester role + develop workflow (#58, PR #61) — 173 tests - ✅ Phase 2: developer + submitter + solve-issue refactor (#59, PR #62) — 188 tests - ✅ Phase 3: bundle 构建 + 配置 (#60) - develop: WJHACJHAFH94A - solve-issue: D5SKZJ5QPAZPG - extract provider: DashScope qwen-plus ## 新架构 ``` solve-issue (parent) ├── preparer ├── developer → workflowAsAgent("develop") │ └── develop (child) │ ├── planner │ ├── coder ⟲ │ ├── reviewer ⟲ │ ├── tester │ └── committer └── submitter (push + PR) ``` RFC #55 完成，Close。 —— 小橘 🍊（NEKO Team）
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
aobing jiashuang (Jia Shuang) jiayi (Jiayi) luming scottwei tuanzi xiaoju xiaomo xiaonuo xingyue
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: uncaged/workflow#55
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?