WhyBuddy: Instructions file for Kiro

Web-AIGC Runtime 主线检查点（2026-04-23，主线接线后更新）

范围

本文不是补 specs，也不是给单个节点补设计文档。

本文件只做一件事：整理当前主仓 runtime 主线已经真实打通的节点族谱，并按以下五个维度做中文检查点归档：

• mainline wiring
• built-in
• extra adapters
• wait-resume
• audit-observability

目标是明确当前 runtime 主线已经具备哪些真实能力，哪些入口已经进入主服务，哪些节点已经进入主线执行面，哪些节点已经带上等待/恢复机制，以及哪些运行时事件已经进入 replay / audit 镜像。

补充口径：

• 本次文档属于“主线接线后更新”，重点补记 server/index 主服务入口、workflows 路由面与 RAG / MCP 共用依赖接线的最新状态。
• 本次更新说明的是“主线已经接上哪些真实入口与共享依赖”，不等于“所有节点 observability / telemetry 已经全统一”。

一、总览结论

截至 2026-04-23，web-aigc runtime 主线已经不再是空骨架，而是具备了以下五层结构：

1. 一层主服务入口接线面。 负责把 Web-AIGC route 面、runtime extra adapters 注册面、RAG 共享依赖面和 workflow runtime 治理入口接到主服务入口。

2. 一层内建 runtime adapter。 覆盖最小流程控制、对话、结束节点、赋值节点和人工选择节点。

3. 一层 extra runtime adapter。 负责把已经落地的 Web-AIGC 节点逐步接入主线 runtime，而不是只停留在独立 route 层。

4. 一层 wait / resume 控制面。 已覆盖人工选择、参数采集、人工审批型 mcp、高风险 transaction_flow，以及 terminate / retry / escalate 等运行时控制入口。

5. 一层 runtime observability bridge。 已把核心 runtime 事件镜像到 replay / audit，并形成节点成功、失败、等待输入、变量赋值、跳转、重试、升级、终止等最小可观测面。

这说明当前 runtime 主线已经从“定义阶段”进入“主服务接线 + 编排执行 + 控制恢复 + 观测治理”并行收口阶段。

二、主线接线检查点（主线接线后更新）

以下内容是本次“主线接线后更新”需要单独补记的事实，重点不在新增 spec，而在于确认这些能力已经被 server/index 与 workflows route 真实接到主服务主线。

1. server/index 已承担 route 面与 runtime 注册面的双重接线

当前 server/index 已不只是在启动 web-aigc 相关依赖，而是同时完成两类主线接线：

• route 面：/api/chat、/api/mcp、/api/web-qa、/api/vector-update、/api/vector-delete、/api/rag/risk-actions 等 Web-AIGC 入口已经挂到主服务入口。
• runtime 注册面：registerWebAigcRuntimeExtraAdapters(...) 已在同一入口被调用，extra adapters 不再只是“代码存在”，而是已经有主服务级注册动作。

这意味着当前检查点不能再把 Web-AIGC 视为“散落 route + 独立 adapter”，而应视为“已在主服务入口形成 route 面与 runtime 注册面双接线”。

2. chat / documentSearch 已形成同源注入链

当前 chatDocumentSearch 已同时进入三处主线位置：

• createChatRouter(...)
• serverRuntime.documentSearch
• registerWebAigcRuntimeExtraAdapters(...)

这带来的实际变化是：

• chat route 与 runtime chat 节点开始复用同一份文档检索能力。
• extra adapters 中依赖 document search 的节点注册时可以直接拿到同源注入，而不是各自重新拼装检索依赖。