research: score Jev intent variants with the previous turn

The earlier report had no previous-turn rows. This run measures V0, V1, V2, and Flash on the re-extracted corpus and records that the real sample is not representative of the simulated set.

Co-authored-by: Cursor <cursoragent@cursor.com>

BLOCKED.md

@@ -1,10 +1,8 @@
 # BLOCKED
 
-## Jev 意图 v2：staging 库与 Flash 凭据（2026-09-27）
+## ~~Jev 意图 v2：staging 库与 Flash 凭据（2026-09-27）~~
 
-- 缺 staging 库。主机 `118.26.111.127` 端口 22 通，仓库变量里的用户是 `ubuntu`（不是 README 示例里的 `deploy`）。本机三把私钥（ed25519、rsa、jd pem）对 `ubuntu` 和 `deploy` 都被拒，没有 `~/.ssh/jyotisha-staging`。Gitea 里的 `STAGING_SSH_PRIVATE_KEY` 保存后读不回。本机 Docker 里的 Postgres 没有 `agentic_rectification_turns`。09-19 交来的 157 条没有 `turn_id` / `case_id`。替代证据：V0 用那次缓存重算，有上一轮 = 0，结论写缺数据，没有用空上一轮去打 V1/V2。
-- DeepSeek key 已通：合成样本 1 次，响应 `model=deepseek-flash`，1067 ms。Flash V0 仍用 09-19 缓存（157 条 intent 89.2%）。Flash+V1 还要等上一轮，未跑。
-- Jev key 已通：合成样本 V0 / V2 各 1 次，响应 `model=jev-1.13.0`。这几次不进计分。SDK 仍是 `typesafe-sdk 0.7.0`。
+已解除（2026-09-27，本机）。`deploy@118.26.111.127` 与 `~/.ssh/jyotisha-staging` 能进 staging，抽出 715 条带 `case_id` 的来源 B（有上一轮 634）。上一笔「ubuntu 才是用户、deploy 被拒」是当时那台机器没有这把密钥。Jev 与 Flash 都打完，结论在 `docs/research/jev_intent_2026_09_27.md`：**缺数据**（来源 B / C 同层差超过 10pp）。09-19 的 `source_b.jsonl` 仍不在本机，旧 157 条对不回 `turn_id`，记在进度偏离里，不再挡抽取。
 
 ## TASK-rectification-telemetry：真实 PostgreSQL 测试与登录态后台待验（2026-09-26）