docs: rename readonly analysis to offline investigation

docs/reference/observability.md

@@ -10,6 +10,14 @@ UniDesk 的可观测性优先级高于静默成功。CLI、服务日志、Docker
 
 因此，CLI、Web、trace 和 issue 评论中的状态字段必须避免把“已观测到缺口”“已显示失败原因”“已提供诊断入口”表达成“问题已解决”。如果当前阶段只能增加可见性，输出应明确标记为诊断进展或阻塞定位；不得关闭对应功能 issue，不得把观测增强当作验收通过。
 
+## Offline Investigation
+
+用户要求“离线调查”时，统一使用这个术语，不再写成“只读流程”“只读调查”或“只读分析路径”。离线调查的边界是用既有证据定位问题：OTel/Tempo 中已经采集的 trace、`platform-infra observability ...` 的离线 analyze/diagnose 输出、已有 `web-probe observe` / `web-probe sentinel` artifact 与 `observe analyze` 报告、代码静态分析、配置/YAML 静态读取，以及必要的 `../opencode` 静态对比。
+
+离线调查不得新开 `web-probe observe/run/script`、不得触发 dashboard/manual quick verify、不得部署、rollout、重启、写数据库、改 Secret 或改变业务运行面。可以读取已有运行记录、状态表、报告索引、source checkout、OTel trace 和离线 artifact；需要 GitHub 写入时只允许在结论阶段通过 `$unidesk-gh` 新建或评论分析 issue，并标明目标合并分支或运行 lane。
+
+离线调查遇到 OTel 或 analyze 不好用时，先改进工具再继续业务结论。典型触发包括：OTel 查询缺少目标运行面、service path、business trace 映射、error span 摘要或 `--grep`/`--limit` drill-down；`diagnose-code-agent` 不能区分 observability gap 与业务失败；`observe collect/analyze` 解析失败、输出不可界定、不能按 run/observer/trace/sample 定位、只给 dump 或缺少 root-cause signal；sentinel report 不能把 runner API、SQLite index 和 artifact findings 对齐。工具改进应优先落在 CLI/analyzer/summary/parser 或 instrumentation 的可见性层，并用既有 trace/artifact 做回归验证；若工具改进需要实际部署或新采样，必须先把离线调查结论停在“工具缺口”，再取得明确授权后进入对应运行面流程。
+
 ## Zero Implicit Fallback
 
 运行时异常、投影写入异常、序列化异常、ReferenceError/TypeError、不可达上游、provider 不可用、trace 同步失败和状态机非法转移不得被隐式 fallback 吞掉。任何 catch 后继续返回旧值、空值、默认值、legacy 查询、二次来源仲裁或“看起来成功”的行为，都必须改成以下两类之一：