fix(rectification): bind skill before provider run

docs/BUG_HISTORY.md

@@ -3480,3 +3480,18 @@
 - 防复发：新增管理业务时只能在登录、权限、Origin、原因和审计边界内扩展；不得把邮箱 OTP 放回公共业务确认弹窗或新建操作级 reauth API。账户级 MFA 与普通用户身份验证必须保持独立。
 - 相关记录：BUG-155、BUG-156
 - 修复版本：本地未提交候选
+
+## BUG-208 | 生时校正 opening 首步依赖模型主动加载 Skill，失败时只返回 run.started → run.failed
+
+- 状态：resolved（staging 发布候选，待质量门禁与业务验收）
+- 首次发现：2026-08-16
+- 最近更新：2026-08-16
+- 影响面：`POST /api/rectification/agent` 的 V9 Agentic Rectification opening/普通 turn、Skill 绑定收据、首步 Case 读取与公开 NDJSON 事件。
+- 用户现象：已通过鉴权、Case/Session 绑定和模型校验的 opening 请求，只收到 `run.started` 后紧接 `run.failed`，没有可见的 Skill、Case 或回答事件。
+- 触发条件：服务端已经通过 `agent.getSkill()` 加载并核验 Case 绑定的不可变 Skill，但首个 provider step 仍使用自动工具选择；模型直接回答，或先调用 `rectification-read-case` 而没有先主动调用框架 `skill` 工具时，运行器按 `skill_not_loaded` / `skill_not_bound` fail closed。attempt 内的活动与文本在成功前统一缓冲，因此该合同错误在公开流中折叠成只有 `run.started → run.failed`。
+- 根因：Skill 的真实性与版本已经由服务器加载和校验，但运行合同仍把“是否完成绑定”交给模型是否主动选择 `skill` 工具，形成服务器事实与模型行为之间的不一致；首步 Case 读取同样没有由服务器强制。该缺陷可确定性复现用户现象，但在缺少 staging 运行日志时不据此断言某个具体 provider 一定返回了直接文本或特定工具序列。
+- 修复：要求 `agent.getSkill()` 返回非空指令，并将其作为本 attempt 的服务器 system bootstrap 注入；在 provider 执行前持久化唯一 Skill receipt 和 `skill.bound` phase，并将 Skill 标记为已绑定。通过 Mastra `prepareStep` 把 step 0 的可用工具缩减为 `rectification-read-case` 且强制调用；重试提示一并放入 bootstrap，不再覆盖 stream instructions。模型若冗余调用 `skill` 不会重复写入收据，其他校正工具在 `case.loaded` 前仍继续 fail closed。
+- 验证：新增回归覆盖服务器 Skill 指令注入、首步强制 `rectification-read-case`、无需模型调用 `skill` 即可完成、Skill receipt 只写一次，以及 `getSkill()` 缺失时 provider stream 不得启动。Rectification Agent/stream/Skill registry 聚焦测试 53/53 通过；目标 ESLint、TypeScript `--noEmit` 与 `git diff --check` 通过。部署同构 Docker `build` target 成功，镜像内 `@mastra/core` 为 `1.50.1`。
+- 防复发：服务器已经确定的 Skill 身份、指令和首个事实读取步骤不得再依赖模型自动选工具；所有 provider 调用前必须完成可审计的 Skill 绑定，首步工具面保持最小化，并继续以最终 `run.completed`、持久化 Turn 和计费不变量作为部署后验收标准。
+- 相关记录：BUG-177、BUG-198、BUG-206
+- 修复版本：本次 staging 发布候选（精确 SHA 以远端 staging 与健康检查验收为准）