# PROGRESS · 明说要校正就直接进入（BUG-1306，2026-10-12）

分支 `codex/rectification-explicit-entry-20261012`，基线 `e6baff95`。未 push，未部署。

## 结论

用户这一轮明确要求做生时校正时，直接打开校正：不先写解读，不用点卡。是否明确要求由模型填写 `explicitRequest`，不用关键词。推得不准时的主动提议仍走卡片。做不了时用一句话说明。普通对话的规则写明不承诺收窄出生时间，也不在对话里收集经历做校正。申报时段的大运、子运只说在哪一段附近。

## 实现

沿用现有工具 `offer-birth-time-rectification`，不新建工具。服务端判定仍是 `decideRectificationOffer`。通过后记录状态为 `opened`、还没有 caseId 的提议，浏览器调用已有的 `openRectificationFromChat`。已有进行中的 case 不新开，查到会话就接着打开。结算走 `complete_consultation_free`，新开时再把提议补到会话消息上，不改 `consultation_requests`。`Home()` 没有新增 `useState` / `useRef`。

## T0 给产品的查法

本 worktree 没有 staging 主机，读不到 web 容器日志，也没有数据库。不阻塞实现。

只查该时段 web 容器日志里的 `[agent-observability]`：

1. `toolCalls` 里有没有 `offer-birth-time-rectification`。
2. 该次调用的 status（有没有放行、有没有 `offered`）。
3. 该会话的 `messages` 里有没有 `rectificationOffer` 这个字段。

不要打开回答正文，不要查看出生资料。

## T5

环境里没有可用模型凭据。`MODEL_PROVIDER_CONFIG_ENCRYPTION_KEY` 与常见供应商 key、数据库连接变量都不在本机环境里（只看了是否存在，没有读取值）。供应商 key 在管理端数据库里加密保存，本机没有数据库，不能解密，也没有调用模型。八个场景写在 `docs/testing/rectification-explicit-entry-20261012.md`。

## 既有断言

| 原值 | 新值 | 原因 |
| --- | --- | --- |
| `rectification-in-chat-20261007.test.ts` 的断言原文没有改。 | 无。 | 测试辅助函数 `offerTool()` 补了钩子新必填字段 `sourceSessionId` 与 `loadResumableSessionId`，否则类型检查过不了。期望值没有改。 |
| `consult-evidence-card-telemetry-20260927.test.ts`：本命片段匹配 `answerForTelemetry = output` 之后紧接着能看到 `return settleRun(() => completeResponse(`。 | 非直达仍是 `if (!state.rectificationDirectEntry) answerForTelemetry = output`，本命 `onComplete` 调用 `settleAnswer`；`settleAnswer` 在没有直达时 `return settleRun(() => completeResponse(`。 | BUG-1306：直达轮不把模型正文当回答，结算改走 `complete_consultation_free`。普通本命轮仍记 telemetry，仍走 `completeResponse`。 |

## 验证

| 命令 | 结果 |
| --- | --- |
| `npx tsc --noEmit`（frontend） | 0 错 |
| `npm run lint` | 0 error，125 条 warning，都是既有未使用变量和 hook 依赖，没有新增 error |
| `rectification-explicit-entry-20261012` + `rectification-in-chat-20261007` | 26 通过，0 失败 |
| 合同套件（agentic runtime、stream recovery、birth accuracy、workflow contract、home shell、smalltalk、composer、entrypoint、rectification entry） | 236 条，235 通过。唯一失败：`consultation-agentic-runtime.test.ts`「personal Agent exposes the Jyotish Skill and named server tool」。Windows 建 Skill 符号链接 EPERM。该测试与 `skill-package-registry.ts`、`skill-binding.ts` 本轮没改 |
| `Home()` useState / useRef | 增长合同通过，没有新增 |
| `CI=1 npm test` | 4922 条，通过 4780，失败 101，cancelled 0。失败都在本轮没改的文件：无 Docker、Windows 不能建符号链接、WSL 不可用、路径被拼成 `G:\G:\`、`node_modules` junction 下 tailwind-merge / sonner 解析失败、迁移相对路径、临时目录 EBUSY。唯一由本轮源码形状引起的是 telemetry 那条，断言已按上表改过，该文件再跑 4 条通过。`consult-single-pass-answer-20260927.test.ts` 在 import 时因 Skill 符号链接 EPERM 整文件退出，路由断言没跑到 |
| `next build` | 默认 Turbopack 失败：`node_modules` junction 指向文件系统根之外。`npm run build -- --webpack` 编译成功（7.8 分钟），TypeScript 通过（4.1 分钟）。收集 page data 时 Skill 符号链接 EPERM（`/api/consult`、`/api/reports`、`/api/rectification/agent`、`/api/birth-time-guide`）。没有路由表，因此没有证明 `/` 仍是 Static，也没有首屏 gzip。没有 `npm install`，没有删 junction，没有改 next 配置。 |

## 环境缺口

- T0：无 staging `docker logs`，无数据库。
- T5：无模型凭据，未调用模型。
- 定向套件里的 Skill 符号链接 EPERM 是本机 Windows 限制。
- `frontend/node_modules` 是指向主仓的 junction。没有 `npm install`，没有删 junction。
- `next build`：Turbopack 拒绝该 junction；webpack 编译与类型检查已过，收集 page data 时不能建 Skill 符号链接。`/` Static 与首屏 gzip 未测。