# 真人核对 · staging 单域咨询耗时（外网证据缓存，2026-09-15）

执行环境无 staging 登录态。下列条目留给有真实账号的人在 staging 走查。本单自动化不替代这些。

目的：同一张盘、同一个问题域连发两轮，记录 `consultationToolDurationMs`。第一轮冷（可能等外网），第二轮应命中「盘 + UTC 日期」缓存，接近本地计算。

代码注释里的域上限 3 是按「staging 实测三域共 62.9 秒」反推的，即一域约 21 秒。本机同样调用只要约 0.5 秒。**本单不改三域上限**；若单域已显著低于 21 秒，把数字写进进度记录，放宽另开单。

## 准备

1. 打开 `https://staging.jyotisha.chat/login` 并登录（用自己的受控账号）。
2. 确认 `https://staging.jyotisha.chat/api/health` 的 `deployment.gitCommit` 等于含本单代码的那次 staging 提交。
3. 选一张**当天还没问过**的盘（或等 UTC 零点后再测），避免误用旧缓存。不要把出生资料贴回对话。

## 冷启动（第一轮）

4. 新建对话，只问一个域（例如事业）。不要点「深入看今日」。
5. 等回答出来。记下：
   - 主观等待 `____` 秒
   - 若浏览器/服务端日志能看到 `consultationToolDurationMs`：`____` ms
   - 技法表「VedAstro 云状态」是 executed 还是 blocked：`____`

## 同日第二轮（应 0 等待）

6. 同一条对话里，用同一张盘再问同一域（换一句问法即可）。
7. 记下：
   - 主观等待 `____` 秒
   - `consultationToolDurationMs`：`____` ms
   - VedAstro 云状态：`____`
8. 第二轮应明显短于第一轮，且不应再出现「空等约 1.5 秒再 blocked」。

## 跨日（可选，UTC 过零点后）

9. 第二天用同一张盘再问同一域。第一句应马上有回答（用昨天的证据），证据里能看出是哪一天的快照；下一轮才换成当天。
10. 点「深入看今日」时，不得沿用昨天的快照；没有当天的就走原来的 1.5 秒有界等待。

## 回填后怎么处理

把 5、7 的两组数字交给验收方，写进 `docs/tasks/PROGRESS-consultation-external-evidence-cache-20260915.md`。若单域已稳定低于 21 秒，结论写成「三域上限可以放宽到 N」的依据，**不要在本单改上限**。

**在这份清单回填之前，任何人不得声称「staging 单域耗时已验证」。**