WhyBuddy: Instructions file for Kiro

Web-AIGC 58 Spec 并行执行总计划

文档目标

本文用于把当前保留的 58 个 web-aigc 迁移 spec，组织成一套可以真正并行推进的执行方案。

目标不是把 58 个 spec 同时散开乱做，而是：

• 尽可能提高并行度
• 尽量避免共享文件冲突
• 让多 Agent / 多工作流 / 多 worktree 可以稳定推进
• 让 sliderule 在迁移过程中持续保持可集成、可回归、可收口

范围

当前范围固定为：

• 6 个平台级 spec
• 52 个节点级 spec

总计 58 个 spec 目录，每个目录包含：

• requirements.md
• design.md
• tasks.md

一页结论

结论先说清楚：

1. 这 58 个 spec 可以并行做。
2. 但不能按 58 个单点同时编码。
3. 正确方式是“平台先收口一轮，节点按能力簇并行，最后集中联调与治理补齐”。
4. 对于一台 20 核、32G 内存的机器，推荐：
   • 文档 / 设计阶段并发：10 - 12 个 Agent
   • 骨架编码阶段并发：8 - 10 个 Agent
   • 集成联调阶段并发：3 - 4 个 Agent
5. 夜间自动推进时，最理想的组织方式是：
   • 1 个主控 Agent
   • 3 个平台 Agent
   • 6 个节点能力簇 Agent
   • 1 个集成 / 回归 Agent

换句话说：

• 不是 58 个 Agent 一起冲
• 而是 10 - 11 个有边界的 Agent 并行推进

基本判断

真实结构不是 58 个“节点”

当前保留集合其实是：

• 52 个节点 spec
• 6 个平台 spec

所以执行时必须区分：

• 平台骨架
• 节点能力
• 高风险动作
• 最终集成与治理

扩展性来自统一执行骨架，而不是 spec 数量

真正的扩展性来自以下 6 个统一点：

• 统一领域模型
• 统一节点输入输出契约
• 统一图运行时状态机
• 统一实例 / 会话 / 任务投影
• 统一 replay / audit / lineage
• 统一 permissions / security gate

如果这些不先收口，哪怕并行写了很多节点，也只会形成一堆局部实现。

当前代码层高冲突区域

以下文件或模块属于并行期的共享热点，必须严格控制 ownership：

• shared/workflow-runtime.ts
• shared/workflow-kernel.ts
• shared/workflow-input.ts
• shared/mission/contracts.ts
• shared/audit/contracts.ts
• shared/permission/contracts.ts
• server/core/workflow-engine.ts
• server/core/mission-orchestrator.ts
• server/routes/workflows.ts
• server/routes/tasks.ts
• server/routes/replay.ts
• server/routes/audit.ts
• server/routes/permissions.ts
• server/routes/lineage.ts
• server/routes/rag.ts
• server/routes/knowledge.ts
• server/routes/voice.ts
• server/routes/vision.ts
• server/routes/a2a.ts

执行原则：

1. 上述文件必须单写者优先，不允许多个 Agent 同时直接改同一热点文件。
2. 节点适配优先向外围新增模块扩展，尽量减少反复改内核。
3. 所有共享契约改动先经过平台主干收口，再放给节点 Agent 跟进。

推荐总并发度

按当前机器配置和仓库体量，推荐如下：

阶段	推荐并发	说明
文档归一	10-12 Agent	CPU 压力低，可高并发
接口与契约设计	6-8 Agent	开始有共享定义，需主控收口
骨架编码	8-10 Agent	并发高但必须分 ownership
联调集成	3-4 Agent	需要顺序收敛
回归 / 收尾	2-3 Agent	统一补测试和治理