sync update from LAN repo (source dhk-1 @ 3b1ec5b4)

frontend-web/docs/multi-agent-background-run-dev.md

@@ -16,7 +16,7 @@
 
 | 事实 | 位置 |
 |------|------|
-| Step2 编排循环（leader → 顺序派 special → leader … 直到 `dispatched===[]` 共识 / `MAX_CYCLES=8`）**完全由前端 hook 驱动** | `src/roundtable-planning/hooks/useStep2Orchestration.ts:992-1204`（recommend）、`1228-1439`（chain） |
+| Step2 编排循环（leader → special → leader …；到全局 `roundtable_room_limit.max_cycles` 配置轮次进入无工具的总控正文收口）**完全由前端 hook 驱动** | `src/roundtable-planning/hooks/useStep2Orchestration.ts`（recommend / chain / dag） |
 | 循环由 `currentStep===2` 的 `useEffect` 启停；离开 Step2 的 cleanup 会 `orchestrationCancelRef.current=true` + `abortAllInFlight()` 中断 | `useStep2Orchestration.ts:1468-1541`（尤其 cleanup `1534-1537`、`1471-1477`） |
 | 共识判定：`leaderRes.dispatched.length===0` → `setHasConsensus(true)` | `useStep2Orchestration.ts:1091-1099` |
 | 进入 Step3：手动点按钮，前置 `hasConsensus===true` | `Step2Panel.tsx:370-381`、`RoundtablePlanningPage.tsx:586-595` |
@@ -456,7 +456,7 @@ checkpoint，一路跑到 Step3 绘制完成。
    只有「查看」进去才能回答（或在弹窗里直接给一个回答框，调用 `resumeJob`）。
 3. **取消**：流程图弹窗/Step2 提供「停止后台」→ `cancelJob`，`status→cancelled`，前端可恢复本地编辑。
 4. **错误恢复**：`error` 事件展示 detail；允许「重试」= 重新 `startJob`（沿用已建 threadIds）。
-5. **MAX_CYCLES / 预算**：后台图内兜底（对齐前端 `MAX_CYCLES=8`），到顶强制收敛并照常进 Step3。
+5. **max_cycles / 预算**：后台与前端统一读取全局 `roundtable_room_limit.max_cycles`（默认 8，2..100），一次会商启动时锁定；到达配置轮次调用 `finalize_only=True`，关闭全部工具并要求总控输出最终总结正文。不能把到顶表现成“已停止”，也不能跳过总结直接进入 Step3。
 6. **多 worker**：严格遵守 Phase 3 的「状态进 DB+checkpointer、SSE 走 loopback」；部署若多 worker
    需 sticky 或全靠 DB 态（推荐后者）。
 7. **清理**：`roundtable_jobs` cleanup cron（活跃保护、先删 CP 再删 DB），与 draft 生命周期对齐。

frontend-web/docs/multi-agent-business-chain-dev.md

@@ -311,13 +311,13 @@ chain 模式的 Step 2 init **完全复用** `initMultiAgent`：`agentNames = ch
 
 ### 阶段 3 · 业务链条选择卡片列表（1.5 天） ✅ 已完成
 **目标**：弹窗「业务链条」面板里选链条。新增 `components/BusinessChainPicker.tsx`，替换阶段 2 的占位。
-- [x] 进入该 Tab 时 `listChains()` 拉本人链条 + `listAgents()` 取存活 id/名称，渲染**卡片列表**：
+- [x] 进入该 Tab 时 `listChains()` 拉本人链条渲染**卡片列表**（席位存活/名称用链条响应自带的读时计算富化字段 `seat.available`/`seat.live_name`，**不再实时拉 `listAgents()`**，见 §11）：
   - [x] 卡片标题（链条 title）+ 「N 席」徽章 + 选中 ✓；描述行。
   - [x] 标题下一排**智能体名 tag**：按链条顺序**从左到右**、不同颜色（`getAvatarTypeFor`→`chainTagClasses`），tag 之间插 `→`（`ArrowRightIcon`）箭头连接（`seats[0]` 最左、先发言）。
   - [x] 底部「配置链条」按钮（跳 `roundtable/chains`）。
 - [x] 空态：无链条时引导「去配置页面创建第一条业务链条」+ 按钮。
 - [x] 选中一条 → 高亮（`ring-primary`）；底部「进入研讨」`onConfirm({ agents: 存活席位有序, mode:"chain", chain:{id,title} })`。
-- [x] 链条里有 agent 已不存在（被删）→ 该 tag 置灰删除线 + `title` 提示 + 卡片下方 amber 警告；confirm 按**存活席位**过滤；存活 < `CHAIN_MIN_SEATS` 则禁用「进入研讨」并提示。agent 列表加载失败时 `existingIds=null` → 不误判删除。
+- [x] 链条里有 agent 已不存在（被删）→ 该 tag 置灰删除线 + `title` 提示 + 卡片下方 amber 警告；confirm 按**存活席位**过滤；存活 < `CHAIN_MIN_SEATS` 则禁用「进入研讨」并提示。存活判定改读 `seat.available`（undefined = 旧后端未标注 → 不误判删除）。
 - **验收**：✅ typecheck 0 新增错误（总数仍 76）。卡片渲染标题 + 彩色 tag + ← 箭头；选链 → `onConfirm(mode:"chain")` → `handleConfirmAgents` 按链条顺序 `setSelectedAgents` → Step 2 左侧「参与角色」顺序 = 链条顺序（**按顺序派活在阶段 4**）。**人工 UI 验收待跑**。
 - **箭头方向**（已确认）：tag 左→右排列、`→`（`ArrowRightIcon`）连接，`seats[0]` 最左、先发言，箭头顺读即链条研讨顺序。
 
@@ -396,5 +396,42 @@ chain 模式的 Step 2 init **完全复用** `initMultiAgent`：`agentNames = ch
 | 后端链条持久化 | `offline-backend-20260512/backend/packages/harness/deerflow/persistence/roundtable_chains/` | 新增 |
 | 后端链条路由 | `offline-backend-20260512/backend/app/gateway/routers/roundtable_chains.py` | 新增 |
 | 后端 store 接线 | `offline-backend-20260512/backend/app/gateway/deps.py`（`app.state.roundtable_chain_store`）+ `app.py` | 改 |
+
+---
+
+## 11. 席位富化：选链不再实时拉智能体列表（2026-10-23）
+
+**背景**：选链全链路（弹窗打开 / 左栏点选 / 深链自动选链）此前每次都额外全量拉
+`GET /api/agents`，只为两件事——席位**存活判断**（existingIds）与**最新改名**
+（nameById）。慢网下这个大请求严重拖慢选链体验。
+
+**方案**：席位展示所需信息（name 快照本就随链条落库、编辑器保存时刷新）之外，
+「存活 + 最新名」由**后端在返回链条时读时计算**：
+
+- `GET /api/roundtable-chains`（list/get/update 等）对每条链每个 seat 附带两个
+  **只读计算字段**（`ChainSeatResponseSchema`，不落库、create/update 请求 schema
+  不收，存量 seats JSON 零迁移）：
+  - `available: bool` —— 席位智能体当前对请求用户可见（本人/内置/已发布、非私享、
+    非管理员隐藏，`agent_store.list_by_ids` 一次批量 SQL）且不是功能型内置
+    （`roundtable-intent/recommender/coordinator/report` + `roundtable-coordinator-*`
+    前缀，与前端 `filterRecommendCandidates` 排除集逐字对齐）；
+  - `live_name: string | null` —— 智能体当前名称，查不到为 null。
+  - best-effort：agent store 不可用时跳过富化（字段缺省），前端按存活处理。
+- 前端 `ChainSeat` 增加可选 `available` / `live_name`；`buildChainSeatSelection(chain,
+  candidates?)` 的 `candidates` 变为可选——不传时存活 = `seat.available !== false`
+  （undefined = 旧后端 → 视为存活，与旧版「拉取失败不判删」降级语义一致）、名称 =
+  `live_name ?? name ?? agent_id`。
+- 去掉选链路径上的全部 `listAgents()`：`BusinessChainPicker`（打开只剩 1 个
+  `listChains` 请求）、`BusinessChainListDialog`（列表弹窗）、主页左栏点选
+  （**零网络请求**）、固定链（8BF 等）与深链自动选链。
+- 「智能推荐」Tab 与链条编辑器的智能体池**保留** `listAgents()`——那两处真的需要
+  完整候选列表。
+
+**兜底**：智能体在选链之后、进 Step 2 之前被删，`/api/multi-agent/init` 的后端
+404 硬校验照旧兜底（现状即有，非本次引入）。
+
+**测试**：后端 `tests/test_roundtable_chain_seat_enrichment.py`（纯函数 + schema
+不落库 + store 往返）；前端 `src/roundtable-planning/lib/business-chain.test.ts`
+（`pnpm run test:business-chain`，esbuild 打包后 node:test）。
 </content>
 </invoke>

frontend-web/docs/multi-agent-frontend-dev.md

@@ -394,8 +394,8 @@ while !cancelled && cycles < MAX_CYCLES:
   setConsensusPercentage(prev => min(95, prev + 8))
   nextLeaderTask = "各子智能体已就上一轮派活完成交付,请你结合最新结论..."
 
-if cycles >= MAX_CYCLES:
-  toast("⏱️ 已达到最大研讨轮次,自动停止以避免循环")
+if cycles == configuredMaxCycles:
+  leader(finalizeOnly: true, tools: [], prompt: "直接综合已有交付并输出最终正文")
 
 clearAllStreamingSpeakers()
 isOrchestrating = false
@@ -695,7 +695,7 @@ window.__MULTI_AGENT_DEBUG__       = true;  // stream 帧计数（默认开）
 
 ### 12.3 调整 Step 2 编排上限
 
-`RoundtablePlanningPage.tsx` 内 `MAX_CYCLES = 8`，超出会 toast「⏱️ 已达到最大研讨轮次,自动停止以避免循环」。若放宽：注意 `step2RoundtableDialogues` 数组会线性增长，超长讨论需要考虑虚拟滚动。
+收口轮数来自全局设置 `roundtable_room_limit.max_cycles`（管理员设置弹窗「会商并发与收口」，默认 8、范围 2..100），旧服务端或读取失败时回退 `DEFAULT_MAX_CYCLES=8`。一次编排启动时锁定当时值；到达该轮不是停止，而是切换为 `finalizeOnly` 纯正文收口：总控禁用全部工具，综合已经取得的席位交付并输出最终方案；个别席位失败时如实标明缺口。前后台执行路径必须保持一致。
 
 ### 12.4 把 special 改回并行
 

frontend-web/docs/skill-knowledge-and-assistant-knowledge.md

@@ -1,5 +1,7 @@
 # 技能知识归纳与“知识梳理”助手知识库
 
+助手知识库的目录、正文、来源和任务记录读取已提交快照，不等待后台导入的全局写锁，也不重复统计整库内容。导入仍在提交前完成实体及 Wiki 对齐，旧数据在检索、导出时保留兼容对齐。页面和展示权限的读取支持取消及 30 秒超时，失败显示可重试错误，避免一直加载；大目录分页失败后停止自动续页并保留已加载正文。来源列表仅在打开「来源与同步」或「导入 / 导出记录」时请求。
+
 管理员在「技能管理 → 技能知识归纳」中选择一个或多个技能、一个或多个目标，系统按“技能 × 目标”创建后台任务。界面提供总体进度、单项失败重试、实体/关系审核、绑定重归纳、自动同步和两种解绑动作。技能列表通过一次 bindings 查询展示归纳目标，避免逐技能请求。
 
 扫描仅处理知识资料。代码、脚本、锁文件、密钥文件以及 Markdown 代码块不会进入上传、摘要、提示词或知识指纹；ZIP 只读取逐项验证通过的知识成员。自动监听只比较该知识指纹，所以纯代码改动不会产生 stale 状态。