resume-diagnosislisted

# Resume Diagnosis 诊断不是连续时段——你正跑 check 命令，被拉去开会，回来 agent 上下文已被 compact，诊断链路丢失。 ## 接手外来交接包（跨机那一半） 上家把一单打包带过来时（典型：路由与验证在前一台机器上做到一半，真正的大日志在另一台机器上），**不要用 `/diagnose` 重开一单**——那会把它当新问题重新收集、重新路由，得到的是一份与上家不同的现场，而真实状态本来就在包里。 1. **落位（机械动作归脚本）**：`python3 scripts/import_trace.py <包.zip | 包.md | 包目录>`——它校验包、落到 `traces/`、比对知识库版本、点出缺件，并打印一屏交接简报。同名冲突时它落成 `<sid>-imported-<n>` 而**不自动合并**（两台机器为同一个问题各开一单是常态，要不要合并是判断，交人）；同一份包重复接手它不重复落位。 2. **读那句简报 + `traces/handoff/<sid>.yaml`**（外来单才有这个文件，是交接单的机器可读那一份）：来源主机与知识库版本、交接意图（继续定位 / 复核结论 / 转上游）、上家留下的待补材料（`needs`）、未纳入与未内联的清单。 3. **版本不一致照实说**：本机知识库与上家不同时简报会点出来——`excluded_cases` 里的 id 可能不存在、候选排序可能不同。以本机库为准执行，发现候选集与 trace 记的对不上就如实说明，别把差异当成上家写错。 4. **缺件不等于"证据已齐"**：简报点名的 `missing`（单文件 md 通道未内联的大文件、传输丢件）要在第一屏就讲清，并按 `needs` 索取；缺着它们把上家的结论当已验证继续往下推，是把"上家没验完的部分"冒充成已验证。 5. **然后照下面的主流程续接**——外来包接手只负责把现场放到本地，恢复现场与继续定位的规则一条不变。 ## 流程 **先清反馈债——按 `feedback.case` 的取值分三种，别混**：扫到的 state 文件里若有 `feedback.outcome: pending`，先看 `feedback.case` 是**真实 case id**、占位串 `pending-investigation`，还是**空值/缺失**（三种都出现过，定义见 `diagnosis_state.yaml.example`）。 - **真实 case id**（上次命中 case 并给了可应用 fix）：追问“上次 <case-id> 的 fix 应用后解决了吗？（解决 / 没解决 / 部分解决）”——按结果回写该 case 的 confidence（hits/misdiagnoses/last_hit）、trace 记 `{action: feedback, case, outcome}`、把 `feedback.outcome` 从 `pending` 改成实际结果，再进入续接。 - **占位串 `pending-investigation`**（没命中 case，只给了建议）：**不念这个占位串**（它不是 case id），也**不要求回写 confidence**（没有 case 可回写，结算脚本只会跳过它）。这类单等的是**现场材料**：按 trace 里最近一条 `evidence.missing` 与顶层 `last_action` 追问“上次要求的那几项材料拿到了吗”，把新