docs: staging SSH user is ubuntu, DeepSeek key reaches flash

The host answers on port 22. Local keys are rejected for ubuntu and deploy, so the previous-turn extract is still blocked.
2026-09-27 11:52:08 +08:00
parent e3bd3930e3
commit fdb7087b19
2 changed files with 5 additions and 5 deletions
@@ -2,9 +2,9 @@

 ## Jev 意图 v2：staging 库与 Flash 凭据（2026-09-27）

- 缺 staging 库。`~/.ssh/jyotisha-staging` 不在本机，默认密钥连 `deploy@118.26.111.127` 被拒。本机 Docker 里的 Postgres 没有 `agentic_rectification_turns`。09-19 交来的 `source_b.jsonl` 157 条没有 `turn_id` / `case_id`，不能还原上一轮。替代证据：V0 用那次缓存重算，有上一轮 = 0，结论写缺数据，没有用空上一轮去打 V1/V2。
- 缺 `DEEPSEEK_API_KEY`。Flash V0 用 09-19 缓存（生产提示，157 条 intent 89.2%）。Flash+V1 未跑。
- Jev key 已在本机打通：合成样本 V0 / V2 各 1 次，响应 `model=jev-1.13.0`。这 2 次不进计分。SDK 仍是 `typesafe-sdk 0.7.0`。
+- 缺 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`。

 ## TASK-rectification-telemetry：真实 PostgreSQL 测试与登录态后台待验（2026-09-26）

@@ -39,7 +39,7 @@ V0 没有重打接口，state 与 09-19 相同，数字从 `jev_runs_v2.json`

 ## 偏离

-1. 重抽来源 B 被 staging 库挡住，见 `BLOCKED.md`。旧 157 条对不上 `turn_id`，因为交来的文件里没有这个字段。
+1. 重抽来源 B 仍被 staging 库挡住。主机通，登录用户是 `ubuntu`，本机私钥不被接受。旧 157 条没有 `turn_id`。见 `BLOCKED.md`。
 2. 没有拿「上一轮 = null」去打满 V1/V2。那样测的是空字段，不是 Magpie 的喂法。
-3. Flash V0 不可省，所以用了 09-19 的生产提示缓存，没有新的 Flash 调用。Flash+V1 按让步可以缺，这里确实缺。
+3. DeepSeek key 已用合成样本打通（`deepseek-flash`）。Flash V0 仍用 09-19 缓存，没有把 157 条重打一遍。Flash+V1 仍缺上一轮。
 4. 来源 C 没有上一轮，按任务书不跑 V1/V2。V0 用缓存重算，没有再花 900 次调用。