# 2026-09-04 Web Copilot 与 Specialist Diagnosis 回归报告

## 背景与目标

本轮验证面向 Investibook dev 环境中的 Web Copilot 诊断流程，目标是确认：

1. 诊断开始前能够确认时间窗口。
2. Evidence Agent 完成采集后，Copilot 能停在候选诊断方向并等待用户选择。
3. 用户可以选择单个或多个方向，也可以通过输入框反馈新的调查方向。
4. 用户确认后由 `diagnosis-analyst` 执行诊断，并加载对应 family subskill 或 specialist skill。
5. 最终结论能够使用收集到的关键证据，收敛到 case 的核心机制，而不是只匹配表面症状。

本报告汇总 2026-09-04 当天的全部五轮测试，并以 10 个 specialist evaluation case 为最终统计全集。测试过程没有修改产品代码。

## 环境

最终定点复测使用的 dev 镜像：

| 服务 | 镜像版本 |
| --- | --- |
| Backend | `02ee372166064eaf822b3c9dd057fc436092d918` |
| Frontend | `ab884fd35123460ff4e2144fe469696d59582fb9` |
| Evolver | `f9125f4860c092788dc5c4f1353aa25e8227edda` |

说明：当天后续合入的 #1164 修改的是 Evaluation 评分与可信 Web routing 识别，不改变上述 dev 运行时的诊断行为。

## 测试轮次

| 轮次 | 目标 | 规模 | 结果摘要 | 产物 |
| --- | --- | ---: | --- | --- |
| PR #1159 跨入口回归 | 验证 Lark 保持 autopilot、Web 进入 Copilot、非诊断请求不误触发 | 3 个正式 case，另含 smoke/probe | Lark 诊断和非诊断入口符合预期；Web 能停在 checkpoint；Langfuse 正常 | [pr1159-copilot-lark-regression-20260904T015713Z](../../outputs/pr1159-copilot-lark-regression-20260904T015713Z/index.md) |
| Web Copilot 交互回归 | 验证时间确认、单分支选择、自定义多分支反馈 | 2 个 case | 两个 workspace 均自然完成；单分支和输入框多分支都成功传入 analyst | [copilot-postfix-regression-20260904T071941Z](../../outputs/copilot-postfix-regression-20260904T071941Z/index.md) |
| Specialist 全量首跑 | 真实 Web 页面并发运行全部 specialist case | 10 个 case | 10/10 已启动；8 个形成完整诊断产物，其中 1 个 CDC case 机制错误；2 个未进入诊断 | [specialist-web-e2e-20260904T092712Z](../../outputs/specialist-web-e2e-20260904T092712Z/index.md) |
| #1164 定点复测 | 复测 5 个 routing/diagnosis 问题 case | 5 个 case | workspace 与 artifact 已下载，但 Langfuse 因 MinIO 满盘没有写入 trace | [pr1164-copilot-routing-regression-20260904T115949Z](../../outputs/pr1164-copilot-routing-regression-20260904T115949Z/index.md) |
| Langfuse 修复后定点复测 | 用完整 trace 复核 Copilot、routing、specialist 和根因链 | 5 个 case | 5/5 有 trace；4 个自然完成，TX case 因 workspace 预算上限中断 | [copilot-specialist-point-regression-20260904T143354Z](../../outputs/copilot-specialist-point-regression-20260904T143354Z/index.md) |

## 最终结论

从完整 specialist diagnosis 的标准看，本轮 10 个 case 中：

- `PASS`：0 个。
- `PARTIAL`：3 个。主方向或部分机制正确，但未完整命中核心因果链。
- `FAIL`：5 个。完成了流程，但关键证据、分类或根因机制明显偏离。
- `INCOMPLETE`：2 个。没有进入完整 Diagnosis，不能据此评价诊断能力。

当前最稳定的是 Evidence Agent 的基础采集与 Copilot 阶段切换；主要缺口已经从“能否收集数据”转移到“候选分类是否规范、是否加载正确 specialist、是否用关键证据收敛到正确机制”。

## 十个 Case 最终矩阵

评分按现有 100 分结构给出：Workflow 10、Evidence Collection 5、Critical Evidence 30、Evidence Routing 5、Diagnosis 50。表中只保留本报告的最终判断，不并列其他评分口径。

| Case | Workflow | Evidence | Critical | Routing | Diagnosis | 总分 | 最终判断 |
| --- | ---: | ---: | ---: | ---: | ---: | ---: | --- |
| `progressive-resource-growth-during-steady-workload` | 10 | 5 | 30 | 4 | 5 | 54 | FAIL：确认 GC/内存增长，但最终转向 CTE/IndexLookUp，未识别 statistics usage delta map 清理缺陷 |
| `intermittent-plan-regression-during-cpu-spike` | 10 | 5 | 20 | 4 | 30 | 69 | PARTIAL：SQL 路由和 AutoX 生效，但停留在通用 plan instability，未识别 Outer Join greedy reorder 与 TopN 参数敏感性 |
| `repeated-component-restarts-during-maintenance-window` | 10 | 5 | 20 | 4 | 10 | 49 | FAIL：识别 OOM 和跨节点重启，但误判为大型 Cop result block，未识别 HeidiSQL 重试 `SHOW TABLE STATUS` 的传播链 |
| `intermittent-query-failures-during-partition-maintenance` | - | - | - | - | - | - | INCOMPLETE：仅完成时间交互，没有形成 routing 和 diagnosis artifact |
| `sustained-node-memory-pressure-during-transaction-workload` | 10 | 5 | 20 | 0 | 5 | 40 | FAIL：选择 storage/IO，未进入 TX specialist，未识别 Async Commit/1PC 与范围扫描触发的锁内存泄漏 |
| `transaction-failure-during-concurrent-upsert` | 10 | 5 | 30 | 5 | 25 | 75 | PARTIAL：识别事务/锁、FK savepoint 和 1105，但把主因归到 unchanged-key locking，未准确说明内部重试未保留 savepoint |
| `component-restart-during-query-cancellation` | 10 | 5 | 30 | 2 | 5 | 52 | FAIL：使用了窗口外 panic 并关联到错误机制，未识别 query cancellation 后 `LazyTxn.Rollback -> session.Close -> clientConn.Close` 路径 |
| `checkpoint-catchup-slow-after-changefeed-resume` | 10 | 5 | 20 | 5 | 20 | 60 | FAIL：CDC 路由正确，也定位到 resolved-ts 后段，但误判为 SinkManager 内存配额/表分布，未识别单次固定 4096 events flush |
| `running-changefeed-with-stalled-progress` | - | - | - | - | - | - | INCOMPLETE：修改时间的 turn 被中止，没有 Evidence、routing 和 Diagnosis 产物 |
| `batch-update-row-processing-anomaly` | 10 | 5 | 30 | 4 | 35 | 84 | PARTIAL：识别任务重叠、write conflict、retry 和 lookup 放大，但未证明 `log_status` 变化后重试导致宽范围扫描的完整链路 |

两个 `INCOMPLETE` case 不纳入平均分。其余 8 个可评价 case 的平均分为 `60.4`。

## Evidence 细分

Evidence 40 分按采集、关键证据和向诊断阶段交接拆分为 5 项：

- 采集与产物完整性 5 分：Evidence Agent 完成采集，标准 evidence artifact 可读。
- 主症状证据 10 分：事故窗口内的核心异常信号已被采集。
- 根因机制证据 10 分：能够区分相似症状、支撑目标机制的特异性证据已被采集。
- 范围/时间/传播证据 10 分：实例范围、变化趋势、事件顺序或跨组件传播关系已被采集。
- Evidence 交接 5 分：关键证据被提升到 workspace report，并正确交给候选分类和 Diagnosis Agent。

| Case | 采集与产物 5 | 主症状 10 | 根因机制 10 | 范围/时间/传播 10 | Evidence 交接 5 | 合计 |
| --- | ---: | ---: | ---: | ---: | ---: | ---: |
| `progressive-resource-growth-during-steady-workload` | 5 | 10 | 10 | 10 | 4 | 39 |
| `intermittent-plan-regression-during-cpu-spike` | 5 | 10 | 0 | 10 | 4 | 29 |
| `repeated-component-restarts-during-maintenance-window` | 5 | 10 | 10 | 0 | 4 | 29 |
| `intermittent-query-failures-during-partition-maintenance` | - | - | - | - | - | - |
| `sustained-node-memory-pressure-during-transaction-workload` | 5 | 10 | 0 | 10 | 0 | 25 |
| `transaction-failure-during-concurrent-upsert` | 5 | 10 | 10 | 10 | 5 | 40 |
| `component-restart-during-query-cancellation` | 5 | 10 | 10 | 10 | 2 | 37 |
| `checkpoint-catchup-slow-after-changefeed-resume` | 5 | 10 | 0 | 10 | 5 | 30 |
| `running-changefeed-with-stalled-progress` | - | - | - | - | - | - |
| `batch-update-row-processing-anomaly` | 5 | 10 | 10 | 10 | 4 | 39 |

8 个可评价 case 的 Evidence 平均分为 `33.5/40`，即 `83.8%`。拆开看：

- 采集与标准产物为 `40/40`，主症状证据为 `80/80`；基础采集链路已经稳定。
- 根因机制证据为 `50/80`。主要缺口是 Outer Join/TopN、Async Commit/1PC 锁内存状态、固定 4096 events flush 这类能排除替代解释的特异性证据。
- 范围、时间或传播证据为 `70/80`。repeated restart 没有收齐客户端重连并在其他 TiDB 节点继续重试的传播链。
- Evidence 交接为 `28/40`。部分关键数据虽然已存在于 artifact 中，但没有稳定进入 canonical route、workspace report 或 specialist 输入；query cancellation 和 transaction memory pressure 最明显。

因此 Evidence 的问题已经不是“普遍采集失败”，而是少数 case 的特异性机制证据不足，以及已收集证据没有稳定进入后续分类和诊断。

## Diagnosis 细分

Diagnosis 50 分按当前诊断流程拆分为 7 项，分值只使用 5 分和 10 分档：

| Case | 信号理解 5 | 假设与分类 5 | Specialist 5 | 根因 10 | 因果链 10 | 反证 5 | 建议与边界 10 | 合计 |
| --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: |
| `progressive-resource-growth-during-steady-workload` | 5 | 0 | 0 | 0 | 0 | 0 | 0 | 5 |
| `intermittent-plan-regression-during-cpu-spike` | 5 | 5 | 5 | 0 | 0 | 5 | 10 | 30 |
| `repeated-component-restarts-during-maintenance-window` | 5 | 5 | 0 | 0 | 0 | 0 | 0 | 10 |
| `sustained-node-memory-pressure-during-transaction-workload` | 5 | 0 | 0 | 0 | 0 | 0 | 0 | 5 |
| `transaction-failure-during-concurrent-upsert` | 5 | 5 | 5 | 0 | 10 | 0 | 0 | 25 |
| `component-restart-during-query-cancellation` | 5 | 0 | 0 | 0 | 0 | 0 | 0 | 5 |
| `checkpoint-catchup-slow-after-changefeed-resume` | 5 | 5 | 5 | 0 | 0 | 5 | 0 | 20 |
| `batch-update-row-processing-anomaly` | 5 | 5 | 0 | 10 | 0 | 5 | 10 | 35 |

未完成的两个 case 不做 Diagnosis 细分。

## 逐 Case 复核

### 1. progressive-resource-growth-during-steady-workload

- Workspace：[ws-1788532674965-140b79381](https://dev.investibook.com/workspace/ws-1788532674965-140b79381)
- 正确路径：把随 uptime 增长的 heap、GC CPU、statement CPU 与 v8.1.1 statistics usage delta map 无法清理关联，指出 restart 只清空状态，升级 v8.5.6 或 v8.1 hotfix 才是修复。
- 实际路径：识别出内存和 GC 异常，也读取了 GC/component family，但最终改判为 SQL plan/CTE/IndexLookUp；没有加载改判后的 SQL specialist，也没有命中 stats cleanup 机制。
- 结论：Evidence 基本够用，失败主要发生在 analyst 的最终分类与机制收敛。

### 2. intermittent-plan-regression-during-cpu-spike

- Workspace：[ws-1788532699488-ecf0255d9](https://dev.investibook.com/workspace/ws-1788532699488-ecf0255d9)
- 正确路径：识别 TiDB v6.5.6 Outer Join reorder 的 greedy 非 cost-based 路径，以及参数是否命中 TopN 对估算和 join order 的影响；给出 binding 或关闭 `tidb_enable_outer_join_reorder`。
- 实际路径：正确进入 SQL family 并加载 AutoX，能解释 cardinality 与 scan amplification，也给出 binding；但没有进一步命中 Outer Join、TopN 和配置开关这一组核心机制。
- 结论：路由正确、通用 SQL 推理有效，但 specialist 没有把证据收敛到 case-specific 根因。

### 3. repeated-component-restarts-during-maintenance-window

- Workspace：[ws-1788514120004-12145b56a](https://dev.investibook.com/workspace/ws-1788514120004-12145b56a)
- 正确路径：关联 HeidiSQL 重复执行 `SHOW TABLE STATUS`、元数据/统计加载未计入原 session、TiDB OOM，以及客户端通过 TiProxy 重连后在其他节点重试形成级联重启。
- 实际路径：确认跨节点 OOM、进程内存超限和 GC 压力，但把根因归为大型 coprocessor result block，并建议限制 Analyze；没有建立 HeidiSQL、`SHOW TABLE STATUS` 和重连重试链。
- 结论：症状级证据充分，触发工作负载和跨节点传播机制缺失。

### 4. intermittent-query-failures-during-partition-maintenance

- Workspace：[ws-1788515014990-83a824c9e](https://dev.investibook.com/workspace/ws-1788515014990-83a824c9e)
- 正确路径：识别旧事务固定旧 Schema、REORGANIZE PARTITION 发布新 Schema、InfoSchema v2 directory-page GC 提前删除旧页，说明必须在新事务中重试。
- 实际路径：workspace 只完成两次开始/时间相关 turn；Evidence 文件存在，但没有 routing 和 `diagnosis-analyst.json`，也没有最终诊断。
- 结论：本轮未完成，不能评价 specialist 能力，必须定点复跑。

### 5. sustained-node-memory-pressure-during-transaction-workload

- Workspace：[ws-1788515094206-a57a29e3a](https://dev.investibook.com/workspace/ws-1788515094206-a57a29e3a)
- 正确路径：把 v7.5.6、Async Commit/1PC、并发范围扫描和 ConcurrencyManager/LockTable retained state 串联，区分停止新增泄漏、重启清理存量和升级修复。
- 实际路径：选择 storage/IO，给出 NVMe 饱和、compaction backlog、GC range deletion、MVCC 旧版本累积的完整替代链；没有进入 transaction specialist。
- 结论：替代解释内部自洽，但与本 case 的事务锁内存泄漏机制不符，属于路由错误后生成了过强结论。

### 6. transaction-failure-during-concurrent-upsert

- 有效完整 Workspace：[ws-1788515306469-d1db663f2](https://dev.investibook.com/workspace/ws-1788515306469-d1db663f2)
- 最新中断 Workspace：[ws-1788533513157-29712d1cf](https://dev.investibook.com/workspace/ws-1788533513157-29712d1cf)
- 正确路径：冗余更新主键触发 FK cascade；并发写冲突导致内部重试，但 cascade savepoint 未被重新创建/保留，回滚 `fk_sp` 失败并以 1105 终止整个事务。
- 实际路径：正确选择 transaction family 并加载 handbook，识别 unchanged-key update、锁竞争、FK savepoint 和 1105；但把核心原因归为 `tidb_lock_unchanged_keys`，没有准确说明内部重试丢失 savepoint。
- 结论：已接近正确机制，但主因仍偏一层。最新复测在 `select_routes` turn 因 workspace `$1` 预算上限失败，这不推翻前一次完整结果。

### 7. component-restart-during-query-cancellation

- Workspace：[ws-1788533941326-3d932094a](https://dev.investibook.com/workspace/ws-1788533941326-3d932094a)
- 正确路径：使用事故窗口内 query cancellation 之后的 rollback cleanup stack，定位 `LazyTxn.Rollback -> session.Close -> clientConn.Close`，关联 query-cancellation cleanup bug，而非 commit path。
- 实际路径：候选使用非 canonical memory/panic route；最终拿窗口外 panic 支撑 OOM/COMMIT 路径并关联错误 issue，偏离事故窗口和预期调用链。
- 结论：这是本轮风险最高的完成态 case。它表面信息完整，但使用了错误时间证据并给出具体错误根因。

### 8. checkpoint-catchup-slow-after-changefeed-resume

- Workspace：[ws-1788516006360-f23358123](https://dev.investibook.com/workspace/ws-1788516006360-f23358123)
- 正确路径：确认 resolved-ts 已恢复而 checkpoint 仍堆积，结合 v8.5.7-release.1 每次 flush 固定最多 4096 events 和约 2000 DML/s，解释每轮只推进约两秒；正式 v8.5.7 多 batch 修复，降低 flush interval 可缓解。
- 实际路径：CDC family 路由正确，也把瓶颈放在 resolved-ts 下游；但将根因推断为 ticdc-2 的 SinkManager memory quota 和 table distribution skew，缺少直接 quota、table-count、flush-duration 和日志证据。
- 结论：方向正确但具体机制错误；缺证据时没有保持足够的不确定性。

### 9. running-changefeed-with-stalled-progress

- Workspace：[ws-1788516508283-2a0c665e2](https://dev.investibook.com/workspace/ws-1788516508283-2a0c665e2)
- 正确路径：关联 Running 状态、checkpoint 停止、Kafka broken pipe/EOF/reset，以及 Pause/Resume 重建 client 后恢复；最终指向 Classic Architecture producer 未正确重建并建议迁移 New Architecture。
- 实际路径：首轮后进入修改时间动作，随后 turn 被取消；没有 Evidence Agent、routing 和 Diagnosis 产物。
- 结论：本轮未完成，必须复跑，不能把取消结果当成 CDC 能力失败。

### 10. batch-update-row-processing-anomaly

- Workspace：[ws-1788533570319-5f3f4acde](https://dev.investibook.com/workspace/ws-1788533570319-5f3f4acde)
- 正确路径：两个 compensation job 在时间和 ID range 上重叠；commit-time conflict 触发 retry，期间 `log_status` 已变化，重试语句宽扫 index 并大量 table lookup 后再过滤。
- 实际路径：识别任务重叠、write conflict、retry、TableLookup/actRows 放大，并给出错峰、缩小 batch 和降低并发；但候选没有提供 SQL route，analyst 也未证明 `log_status` changed-value 这一关键连接点。
- 结论：这是 10 个 case 中最接近通过的结果，但仍缺根因链中决定性的中间环节。

## 分阶段观察

### Copilot 交互

已确认可用的能力：

- Web 请求会先停在时间确认阶段，确认前不会启动 Evidence Agent。
- Evidence 完成后可以停在诊断方向 checkpoint，不会自动执行 Diagnosis Agent。
- 单分支按钮选择能够进入对应方向。
- 输入框反馈可以携带多个方向，`selection.source=feedback`，并交给同一个 analyst 比较。
- Lark 诊断入口仍保持 autopilot；Lark 非诊断问题不会误触发 Evidence/Diagnosis。

仍存在的问题：

- routing artifact 有旧 schema 或缺少 `schema_version`、`label` 的情况，页面无法渲染按钮，只能通过输入框继续。
- 部分 candidate 使用非标准 route ID，例如 `tidb_memory_oom_or_panic`，无法稳定映射到既有 family subskill。
- 多分支按钮链路尚未被严格证明存在传输丢失。现有证据更接近“正确第二分支没有被生成”，而不是“用户点击后丢失”。
- 自动化脚本使用 exact accessible-name 匹配时，会把带 `check` 或“推荐”前缀的按钮误判为不存在。这是测试脚本问题，不是产品按钮缺失。

### 时间确认

时间确认总体可工作，但 `intermittent-plan-regression-during-cpu-spike` 曾写出 `start_utc/end_utc`，而前端期望 `normalized_range.start/end/timezone`，导致页面显示缺少时间。

该 case 中用户在采集前已纠正时间，后续 Evidence 和 Diagnosis 都使用了正确窗口，因此本报告不因这次交互错误扣 Evidence 或 Diagnosis 分。时间修订应计入 Copilot 交互质量；只有错误窗口继续进入采集或最终结论时，才应扣 Evidence/Diagnosis 或判为无效。

### Evidence

8 个进入完整流程的 case 都生成了 Evidence Agent 产物：

- 4 个 case 的关键证据基本完整：progressive resource growth、concurrent upsert、query cancellation、batch update。
- 4 个 case 只达到部分完整：plan regression、repeated restart、transaction memory pressure、CDC checkpoint catch-up。
- Evidence 的主要缺口是 case-specific 信号没有被稳定采集或提升为关键证据，例如 HeidiSQL/`SHOW TABLE STATUS`、Async Commit/1PC + range scan、固定 4096 batch flush。
- Evidence 已不是本轮最长阶段。最终定点复测中，完整 workspace 总耗时为 398.4s 到 851.8s；多个 completed case 的 Diagnosis Agent 本身耗时约 7 到 9 分钟，是当前主要时延来源。

### Routing 与 Specialist

Routing 当前有三类公共问题：

1. 候选结构不稳定：旧 schema、缺字段会让前端无法渲染 checkpoint。
2. taxonomy 不稳定：agent 会生成未注册的 route ID，导致选择结果无法可靠映射到 subskill。
3. analyst 改判后未重新加载 specialist：例如 progressive case 最终转向 SQL，但没有按新分类进入 SQL specialist；memory pressure case 则被错误固定在 storage/IO。

这不是要禁止 analyst 推翻用户选择。用户选择的是待验证假设，analyst 可以改判；但改判后必须显式记录依据，并加载新分类对应的 specialist，或者在证据不足时保留不确定性。

### Diagnosis

本轮主要问题不是“完全没看到异常”，而是从异常到具体机制的最后一段不稳定：

- 通用症状容易识别，例如 OOM、GC、锁等待、checkpoint lag、write conflict。
- specialist skill 有时已加载，但输出仍停留在通用机制，没有使用 case-specific evidence 收敛。
- 在关键证据缺失时，agent 倾向于补出一个看似完整的替代根因，而不是明确写成未证实假设。
- exact known issue 不是每个诊断都必须执行；但一旦回答声称命中某个具体 issue 或版本缺陷，就必须由窗口内证据或后续 code 模块验证，不能仅凭相似 panic 签名直接确定。

## Langfuse

#1164 定点复测期间，Langfuse S3/MinIO 的 `10Gi` 存储达到 100%，导致 telemetry 请求持续返回 500。处理措施为：

- PVC 从 `10Gi` 扩容到 `50Gi`。
- 重启 MinIO 完成文件系统扩容。
- 为 `investibook-dev/` 增加 60 天生命周期规则。
- 清理超过 60 天的旧 observation object。

修复后的 smoke trace 成功写入；最终 5 个定点复测 workspace 均能按 workspace ID 拉到 trace 和 observations。Langfuse 可观测链路本轮判定为通过。

## 成本与耗时

| 测试轮次 | Case 数 | 成本 | 说明 |
| --- | ---: | ---: | --- |
| PR #1159 跨入口回归 | 3 个正式 case + smoke/probe | `$1.3001` | 包含一个 discarded CLI probe |
| Web Copilot 交互回归 | 2 | `$3.3465` | 两个 case 均完整走完三阶段 |
| 10 case 全量首跑 | 10 | `$19.2765` | 单 case 总耗时 30.9s 到 1499.0s |
| #1164 定点复测 | 5 | `$12.2618` | 无 Langfuse trace，但 DB/artifact 完整下载 |
| Langfuse 修复后定点复测 | 5 | `$10.2437` | 最大并发 2，平均总耗时约 677.6s/case |

当天上述测试总成本约 `$46.43`。其中诊断阶段是主要成本和耗时来源，下一步不应继续压缩已经稳定在分钟级以内的 collector，而应减少 analyst 的无效探索、错误分类后的重复阅读和缺证据情况下的替代根因扩展。

## 下一步

### 本 PR 已落实的公共修复

- `diagnosis-routing.json` 只接受 v2 schema 和 11 个标准 taxonomy route；新增原子写入校验，未知 route、重复 candidate、无效 recommendation 或 selection 会被拒绝。
- analyst 可以推翻 Copilot 选择，但改判后必须记录 `classification_override`，加载最终分类 family 及其强制 specialist；否则 report writer 拒绝生成最终报告。
- load-bearing evidence 中的显式时间戳必须位于 canonical window。窗口外样本只能进入 `outside_window_context`，不能直接支撑根因和置信度。

上述修改不改变 collector、Evidence Agent 的查询自由度或 Copilot 选择作为“待验证假设”的语义。

优先级建议如下：

1. `P0`：部署后定点复跑 `sustained-node-memory-pressure` 和 `progressive-resource-growth`，验证 analyst 改判后的 specialist 重载。
2. `P0`：定点复跑 `component-restart-during-query-cancellation`，验证窗口外 panic 不再被用作根因证据。
3. `P0`：提高测试 workspace 的预算上限，单独复跑 `transaction-failure-during-concurrent-upsert`，排除 `$1` 上限造成的非产品中断。
4. `P1`：复跑本轮两个未完成 case：partition maintenance 和 running changefeed stalled progress。
5. `P1`：复跑 repeated restart 和 CDC checkpoint catch-up，验证 case-specific 关键证据能否被采集并传给 analyst。
6. `P1`：修正 Web 自动化按钮定位，按 route ID 或稳定 data attribute 选择，不再依赖带状态前缀的完整 accessible name。
7. `P2`：保留 1 到 2 个已完成 case 做无回归抽样，不需要每次重跑全部高成本 case。

## 产物索引

- [PR #1159 Copilot/Lark 回归](../../outputs/pr1159-copilot-lark-regression-20260904T015713Z/index.md)
- [Web Copilot 交互回归](../../outputs/copilot-postfix-regression-20260904T071941Z/index.md)
- [Specialist Web 全量 10 case](../../outputs/specialist-web-e2e-20260904T092712Z/index.md)
- [PR #1164 定点复测](../../outputs/pr1164-copilot-routing-regression-20260904T115949Z/index.md)
- [Langfuse 修复后定点复测](../../outputs/copilot-specialist-point-regression-20260904T143354Z/index.md)