已确定的产品与工程决策

Agent Board 通用化决策记录

本文件只记录已经达成一致的方向，不包含具体实现设计。后续执行方案以这些决策为边界，避免在 Factory V2 / Factory V3 / Vibe Coding V2 的历史分叉上继续堆功能。

决策 1：主看板使用 SQLite Agent Board

Vibe Coding V2 的用户入口是 `/sol/vibe-coding-v2/sess/:sessionId`，但它的看板 tab 内部复用 `FactoryV2BoardPanel`，后端实际走 `/api/factory-v2/projects/{id}/board-tasks`。这条链路已经覆盖 CLI、Vibe 工作台、headless 执行、运行事件、PR 回流和前端实时更新，应改名并抽象为通用 Agent Board 主链路。

决策 2：看板能力脱离 Solution 复用

Agent Board 的 Skill、UI、API、CLI 必须是通用能力。Solution / BizRole 可以接入；普通 chat 会话即使不使用 Solution，也应该能创建、展示和使用看板。

决策 3：干净切换，不保留重复实现

项目尚未发布，不做向后兼容包袱。Vibe Coding V1/V2、Factory V1/V2/V3 的重复入口和重复实现应合并成一套主链路，不新增 compatibility shim。

决策 4：允许同步修改 Prompt 与 Skill

当前 Prompt / Skill 中存在冲突：Vibe 侧要求不要用 Gitea Issue 管理任务，而 Factory V3 侧又用 Gitea Issue label 管理任务。执行简化时允许同步合并这些提示词和 Skill。

边界结论

Gitea 的定位

Gitea 只作为代码仓库、PR、diff、merge、webhook provider。Gitea Issue 不再作为主看板。

看板状态

主状态统一为 `unassigned / not_started / in_progress / in_review / done`。Gitea `status/*` 只能作为外部映射。

入口关系

Solution、BizRole、普通 chat 都只是 Agent Board 的入口。入口可以提供默认 agent、文案、初始配置，但不拥有独立看板实现。

历史代码

`/factory`、`/factory-v2`、`/factory-v3`、Gitea Issue board UI、旧 Software Factory UI 都应收敛到一个 Workbench + Agent Board 主入口。

为什么这样定

SQLite board-tasks 是 Vibe 工作台的真实看板链路：虽然测试入口是 `/sol/vibe-coding-v2/sess/:sessionId`，但看板 tab 实际走 board-tasks；它已有任务 CRUD、Socket、CLI、headless、事件回流、PR 回流。
Gitea Issue board 是第二套看板：状态、Socket、数据源、自动执行条件都与主链路不同，继续保留会扩大复杂度。
看板不应绑定软件开发：非代码任务也需要多智能体协作，普通 chat 也需要把临时任务沉淀为看板事项。
当前产品未发布：可以做干净切换，避免长期背负 V1/V2/V3 命名和兼容逻辑。