WhyBuddy: Instructions file for Kiro

Web-AIGC 迁移 Spec 执行矩阵

文档目标

本文用于说明当前保留下来的 58 个 web-aigc 迁移 spec，哪些可以并行执行，哪些必须先收口，哪些适合先做文档、后做实现，以及在代码阶段应如何组织并发，避免多人或多线程同时改同一层抽象导致反复返工。

适用范围

本文覆盖以下文档集合：

• 6 个平台级 spec：web-aigc-platform-*
• 52 个节点级 spec：web-aigc-node-*

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

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

核心结论

这 58 个 spec：

• 可以并行推进
• 但不能无依赖地 58 个一起平铺执行
• 最合理的方式是“平台先收口一轮，节点按能力簇并行”

如果是文档推进：

• 并行度可以做到 70% - 80%

如果是代码推进：

• 推荐并发度控制在 8 - 12 条工作流
• 不建议按 58 个 spec 一起开工

2026-04-23 主线接线校准

需要明确：

• 58 / 58 份 web-aigc specs 与 238 / 238 个顶层任务已全部完成，这是已经封板的事实。
• 本文保留的 L0-L5 分层、能力簇和波次，主要用于说明“后续主线增强如何分批并行收口”，不再表示 spec 完成度。
• 2026-04-23 主线已确认新增接线：server/index.ts 已挂载 robot-reply、open-page、mcp、open-dashboard、web-search、web-qa、get-location-info、get-device-info、vector-update、vector-delete 等入口；server/routes/workflows.ts 已挂载 open-report 子路由，并承载 /api/workflows/:id/runtime/run、/api/workflows/:id/runtime/retry、/api/workflows/:id/runtime/escalate 的 workflow runtime governance 控制链路；RAG vectorStore 已通过 ragDeps 暴露给 /api/rag、向量治理与风险动作路由。
• 因此，文中“优先实现”“延后”“空白项”等表述，都应理解为主线补线优先级，不等同于“未启动”或“spec 未完成”。

执行原则

原则 1：先平台，后节点

6 个平台级 spec 是 52 个节点 spec 的上位约束，必须先形成第一轮统一结论，否则节点级实现会反复返工。

原则 2：按能力簇并行，不按单节点乱并行

节点级 spec 看似有 52 个，但真正落地时应该按能力簇推进，而不是 52 个节点平铺推进。

原则 3：文档并行度高于代码并行度

文档阶段只要术语、状态、接口归一，很多组可以同时写；代码阶段则受共享文件、共享接口、共享状态机影响更大。

原则 4：共享写入范围必须隔离

同一批并行工作如果都要改：

• shared 契约
• server/core/workflow-engine.ts
• server/routes/workflows.ts
• server/routes/tasks.ts

那么冲突概率会急剧上升，必须分批。

分层执行模型

建议把 58 个 spec 的推进拆成 5 层。

L0：术语与契约收口层

这是所有并行工作的前置层，不是大量写代码，而是先把语言统一。

包含：

• 图定义、图版本、图实例、节点执行记录、边跳转记录等术语
• 状态映射
• 输入输出契约命名
• replay / audit / session / mission 的挂接关系

主要依赖：

• web-aigc-platform-domain-model

并发建议：

• 低并发
• 1 - 2 条工作流即可

L1：平台骨架层

这是第一批可以并行但不能失控并行的层。

包含：

• web-aigc-platform-domain-model
• web-aigc-platform-runtime-engine
• web-aigc-platform-mission-projection
• web-aigc-platform-session-instance
• web-aigc-platform-observability-audit
• web-aigc-platform-security-governance