public-factory-v3 分支整理 / 讨论稿

Agent Board 分支整理与简化方案

本方案已综合对比三份方案后更新：分支 public-factory-v3 相对 origin/main 新增了 126 个文件变更、12093 行新增、1059 行删除。它不是单点功能分支， 而是一组围绕 Factory V3、Vibe Coding V2、Gitea 看板、headless 自动运行、PR 回流和工作台 UI 的迭代提交。

三套方案排名

1

factory-v3-simplification-plan.html

排第一。它对当前分支的重复代码、hard code、三步执行路径和删减量估算最完整， 最适合作为落地执行基准。

2

agent-board-branch-simplification-plan.html

排第二。它的优势是基于本地代码证据列清楚了两套看板数据源和关键取舍， 但原版执行拆分偏细，落地节奏不如第一份直接。

3

agent-board-design-plan.html

排第三。它的架构方向正确，适合做最终目标图，但缺少对当前 12000 行变更的代码级拆解和删除路径。

评价维度 第一份 factory-v3 第二份本方案原版 第三份 design-plan
对当前分支的代码事实覆盖 强：明确列出文件、重复模块、行数和 hard code。 强：更强调代码证据和取舍边界。 弱：偏目标架构。
执行可操作性 最强：后端、前端、Solution/Skill 三步清楚。 中等：7 阶段更稳，但偏碎。 中等：有顺序，但缺少当前代码切入点。
通用 Agent Board 方向 强：目标是三套实现收敛为一套通用机制。 强：更明确普通 chat / Solution / BizRole 都只是入口。 最强：抽象边界最清楚。
风险控制 中等：删除力度明确，但第一步同时改名、删链路、合并 runtime，PR 可能过大。 强：先确认 SQLite 主看板和 Gitea Issue 删除，再分批做。 中等：风险项有列，但没有验证切片。

综合结论

执行基准采用 factory-v3-simplification-plan.html 的三步主线； 架构目标采用 agent-board-design-plan.html 的 Agent Board Kit / TaskRunner / Provider 边界； 具体落地时保留本方案原版的风险控制：先确认主看板数据源，再小 PR 迁移，避免一次性同时改后端、前端、Skill 和 Prompt。

当前分支全貌

29

个分支 commit，从 Gitea 看板到 PR 回流、Vibe 接入、UI 对比度修复。

12k+

新增代码，主要落在 server routes、web workbench、CLI、Solution skill/prompt。

2 套

看板数据源并存：SQLite board-tasks 与 Gitea Issue board。

区域 新增内容 简化判断
server/routes/factory_v2.py 项目 CRUD、文件/Git/发布、SQLite board task、headless 自动运行、事件同步、PR 结果解析。 功能最完整，应作为 Agent Board 主链路的迁移来源，但需要拆模块和去 Factory 命名。
server/routes/factory_v3.py Gitea Issue board、webhook、butler session、Gitea Issue 触发的 autorun。 是第二套看板，建议删除主看板职责，只保留可复用的 Gitea provider 能力。
web/components/factory-v2 完整看板面板，含任务详情、评论、事件、PR 链接、运行态。 可改造成 AgentBoardPanel，但需移出硬编码人员、API、query key。
web/components/factory-v3 Gitea Issue board UI 与管家入口。 建议管家入口保留为可选应用入口，看板 UI 删除或并入通用面板。
cli/internal/cmd/kanban*.go Agent 使用的 blade kanban 命令。 命名已接近通用，但 API 和默认 solution 仍绑定 Factory/Vibe，应优先迁移。
solutions/builtin/* 新增 software_factory_v3 角色、skill、提示词，同时 Vibe Coding V2 又引用 factory_v3 skill。 提示词重复且冲突，应沉淀为通用 board skill，再让具体入口引用。

明显 hard code 清单

产品/入口硬编码

  • blade kanban update --agent 写死 solution_id = "vibe-coding-v2"。
  • factory_v2.py 多处默认创建 vibe-coding-v2/default session。
  • factory_v3.py 写死 software_factory_v3/default 和 butler。
  • 前端路由并存 /factory-v2、/factory-v3、/sol/vibe-coding-v2。

数据源/状态硬编码

  • SQLite 状态是 unassigned/not_started/in_progress/in_review/done。
  • Gitea Issue 状态是 status/unassigned/status/todo/status/in-progress/status/in-review/status/done。
  • 两套 socket 事件并存：factory-v2:board-task:changed 与 board:updated。
  • 数据库表仍是 software_factory_v2_*，模型类型也仍叫 FactoryV2*。

环境和部署假设

  • host.docker.internal 在后端直接替换成 localhost。
  • BLADE_AGENT_PUBLIC_URL 默认值是 http://host.docker.internal:8020。
  • Gitea 认证散落在 GITEA_URL、GITEA_HOST、GITEA_TOKEN、GIT_PASSWORD、GIT_ACCESS_TOKEN。
  • HEADLESS_TASK_OUTPUT_SCHEMA 强制要求 pr_url，使看板任务默认等于代码 PR 任务。

UI 和人员硬编码

  • FactoryV2BoardPanel.tsx 内置人员名单：刘扬、赵学智、王攀峰等。
  • 人员头像颜色、智能体名、query key、API 前缀都在组件内部写死。
  • VibeCodingWorkbenchLayout 使用 Factory V2 API，但文案和路由仍绑定 Vibe Coding。
  • FactoryV2ProjectPage.tsx 超大页面同时承担 chat、board、code、git、service、publish。

核心判断

建议把看板上升为 Agent Board 通用机制

当前功能的本质不是软件工厂，而是“智能体可创建任务卡片，任务卡片可以分配给某个智能体， 后端自动启动同类或指定智能体的 headless session，运行事件回写到卡片，最终提交结构化结果”。 这个能力可以服务软件开发，也可以服务市场、法务、财务、研究等非代码任务。

入口

普通 chat、Solution、BizRole、Factory、Vibe 只是提供默认上下文、默认智能体和 UI 布局。

→

Agent Board

统一 Project、Task、Assignee、TaskEvent、TaskRun、状态流转、socket、CLI、Skill。

→

Runner / Provider

Headless session 是通用 runner；Gitea 只是 repo/PR provider，不再是主看板。

需要先和你确认的取舍

  1. 主看板数据源：建议确定 SQLite board-tasks 为唯一主看板；Gitea Issue 不作为主看板，只作为可选外部同步或后续 provider。
  2. 通用程度：建议 Agent Board 支持非代码任务，因此 task result 不应强制要求 pr_url；代码任务可额外返回 PR。
  3. 入口保留：建议保留一个统一工作台入口，删除 /factory-v2、/factory-v3 的重复页面；Vibe Coding V2 作为入口配置，不拥有专属看板实现。
  4. 命名策略：建议代码层新模块叫 agent_board，API 叫 /api/agent-board；数据库表可第一阶段保留旧表名，第二阶段再迁移。
  5. 人员与智能体配置：建议人员列表从真实用户/项目成员读取，不在前端组件内写死；智能体来自项目 agent configs 或 BizRole registry。

综合后的执行方案

采用排名第一方案的三步主线，但把第一步拆小：后端命名、Gitea Issue 看板删除、TaskRunner 抽离不要塞进同一个 PR。

主线 目标 采纳来源 关键动作 预计净删/收敛
1. 后端 Agent Board 化 统一数据模型、API、自动运行机制。 第一份 + 本方案 software_factory_v2 类型和 store 迁到 agent_board； 新增 /api/agent-board； 删除 Gitea Issue 主看板； 抽出 task_runner.py。 约 800-1300 行。
2. 前端统一 Workbench + Board 只保留一套看板 UI 和一套项目工作台。 第一份 以 FactoryV2BoardPanel 为基础改成 AgentBoardPanel； 删除 factory-v3/BoardPanel 和 /factory-v3 页面； VibeCodingWorkbenchLayout 改成通用 Workbench。 约 1000-1600 行。
3. Solution / Skill / Prompt 合并 智能体只学习一套看板和任务执行协议。 第一份 + 第三份 新增通用 agent_board skill； 合并 factory_v3、butler_board_guide、task_board_guide； 删除重复的 sf_* guide； 保留 repo/PR 能力为 provider 说明。 约 900-1500 行。

建议 PR 切片

PR 范围 不做什么 验证重点
PR 1 后端新增 agent_board 命名边界，API 加 /api/agent-board，CLI 改指向新 API。 不删前端页面，不改 Solution。 现有 board-tasks CRUD、CLI list/get/create/update、socket 事件仍工作。
PR 2 删除 Gitea Issue board 主链路，保留 Gitea repo/PR provider。 不动 Workbench 大布局。 项目创建、仓库关联、PR 回流还能走 SQLite board task。
PR 3 前端改成 AgentBoardPanel + 统一 Workbench，删除 /factory-v3 页面。 不重写聊天组件和发布组件。 Vibe 入口、项目入口、普通 board 页面渲染一致；流式任务状态正常更新。
PR 4 合并 Solution / Skill / Prompt，删除重复 software_factory_v3 skill 或把有效内容迁到通用 skill。 不新增环境变量，不保留 compatibility shim。 智能体能通过 blade kanban 创建任务、分配任务、提交结果。

更新后的删除预估

按综合方案执行，保守估计可净删 2700-4400 行。 排名第一方案中的 ~3500 行是合理中位数；实际删除量取决于是否立刻删除旧路由 redirect 和整个 software_factory_v3 Solution 目录。

目标目录形态

host/src/blade_agent/host/agent_board/
  models.py           # BoardProject, BoardTask, BoardTaskStatus, BoardTaskEvent, BoardAgent
  schema.py           # SQLite schema, 第一阶段可兼容旧表名
  store.py            # AgentBoardStore
  task_runner.py      # card -> headless session -> events -> result
  result_schema.py    # 通用结果 + 代码 PR 扩展
  repo_provider.py    # 抽象接口
  gitea_provider.py   # Gitea repo / PR / diff / merge

server/src/blade_agent/server/routes/
  agent_board.py
  agent_board_changes.py

web/apps/web/src/components/agent-board/
  AgentBoardPanel.tsx
  AgentBoardTaskDialog.tsx
  AgentBoardEvents.tsx
  agent-board-api.ts

host/src/blade_agent/host/solutions/builtin/agent_board/
  skills/agent_board/SKILL.md

我建议下一步怎么协作

  1. 以 factory-v3-simplification-plan.html 作为执行基准，先确认它提出的三步主线是否成立。
  2. 确认最大产品取舍：SQLite board-tasks 是唯一主看板，Gitea Issue board 删除，Gitea 只保留 repo/PR provider。
  3. 确认 Agent Board 是否支持非代码任务；如果支持，第一批就要移除 pr_url 强制输出，把 PR 结果变成代码任务的扩展字段。
  4. 确认 PR 1 范围：只做后端 agent_board 命名边界 + /api/agent-board + CLI/API 迁移，不碰前端大重构。
  5. 确认是否允许在 PR 4 直接删除 software_factory_v3 Solution 目录；如果不直接删，就先把有效 skill 迁到通用 agent_board skill 后再删。

分支探索记录

已执行的只读检查：

git status --short --branch git log origin/main..HEAD git diff --stat origin/main...HEAD git diff --numstat origin/main...HEAD 关键文件 nl / rg 抽样阅读

当前 worktree：/Users/yangliu35/code-space/blade-agent/.claude/worktrees/enumerated-wondering-rocket。 分支：public-factory-v3。工作区额外存在未跟踪 logs/，本方案未触碰。