docs: BUG-954 根因由服务端日志定死——窗口 Agent 没绑方法块

日志：input-processor jyotish-skill-bound abort ×2，modelStepCount 0、
0 token、整轮 69ms，模型从未被调用。windowJyotishInstructions 从不含
BOUND_METHOD_MARKER，而 getWindowJyotishAgent 照样 attach 绑定，自
9958e00a（08-21）起申报时段每轮必败。abort 与「模型没调工具」同码，
是它藏四周的原因。初版任务书的「模型没调工具」立论已证伪并改写。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0193vBv6w5MV2cifdTUu9H5P

docs/BUG_HISTORY.md

@@ -12510,22 +12510,24 @@
 - 复发自：BUG-947
 - 修复版本：`cd4775ae`
 
-## BUG-954 | 申报时段咨询整轮失败：模型没调计算工具，合同判未完成
+## BUG-954 | 申报时段咨询自 08-21 起每轮秒败：窗口 Agent 绑了 skill 却没把方法块写进系统提示
 
-- 状态：investigating
+- 状态：investigating（根因已由服务端日志确认，修复未做）
 - 首次发现：2026-09-18
 - 最近更新：2026-09-18
-- 影响面：`windowJyotishInstructions`、`consultationWindowPrepareStep`、`consult/route.ts` 申报时段分支、`contractReady()`
-- 用户现象：staging（已部署 `9cdcf96b`）申报时段会话问「未来半年我事业如何？」，等待后 `run.failed code=runtime_contract_incomplete`，提示「Agent 未完成必要的方法与计算步骤，本次不会扣点。」公开事件只有 `run.started` → `skill.started/completed` → `activity loading-method` → `run.failed`。
-- 触发条件：`consultationMode=declared_birth_window`、`theme=general`、`history=[]` 的首轮提问（问题带应期语义）。
-- 已确认事实：
-  1. 回执 `steps` 只有 `skill` 与 `runtime-contract-retry` 两条，`stepBudget.used=2`，**没有任何 tool 步骤**，`workflow.route=declared-birth-window / status=blocked`，`skill.referenceReads=0`、`methodologySections=0`。
-  2. 该形状**不是**供应商 error 块那条路：BUG-938 的修复规定 error 块会追加 `validation model-stream-error failed`、不触发合同 retry、公开码为 `calculation_failed`。本次回执无该步、有 retry、公开码是 `runtime_contract_incomplete`，因此两次 attempt 都是「模型没调工具」。
-  3. `contractReady()`（`stream-agent-response.ts:336-339`）要求 `consultationToolSuccessCount === 1`；未绿时模型正文一律丢弃，所以模型若改成直接写一段文字回答，用户端看到的就是整轮失败而不是那段文字。
-  4. `run-jyotish-window-consultation` 的 `inputSchema` 只有 `question`（`consultation-tools.ts:765-767`），出生数据全部服务端绑定——由模型决定调不调，对计算结果没有任何信息增益。
-- 初判根因（待日志确认）：BUG-923 记录过「提示词是软约束，`toolChoice: "auto"` 不能保证第 0 步调用排盘工具」；BUG-937 因为某些 thinking 供应商拒收 `required`，把第 0 步改回 `activeTools` + `auto`，**等于把 BUG-923 的洞原样放回来**，且没有补第三条路。窗口指令同时写着「每轮必须先调工具」和「`can_answer_precise_timing` 恒为 false，不得给出月份 / 日期 / 大运边界」，而本次问题正是应期语义；模型在冲突下选择不调工具的可能性最大。
-- 待取证据：staging 该 `requestId` 的服务端日志（`modelFinishReason`、是否有 `[consult-provider-error]`、模型是否产出过被丢弃的正文）、本次使用的模型 id 对应的供应商。没有这条日志之前不得把根因写成 resolved。
+- 影响面：`src/mastra/index.ts` `windowJyotishInstructions` / `getWindowJyotishAgent`、`src/mastra/skill-binding.ts` `jyotishSkillBoundProcessor`；`declared_birth_window` 模式的每一轮
+- 用户现象：staging 申报时段会话问「未来半年我事业如何？」，`run.failed code=runtime_contract_incomplete`，公开事件只有 `run.started` → `skill.started/completed` → `activity loading-method` → `run.failed`，回执零 tool 步。
+- 触发条件：任何 `consultationMode=declared_birth_window` 的请求，与问题内容、模型、供应商无关。
+- 根因（服务端日志实证，requestId 脱敏为前八位 `95de38fd`）：
+  1. `docker logs jyotisha-staging-web-1` 命中两条 `[WORKFLOW] Error executing step ... input-processor.step.processor:jyotish-skill-bound: Error: Jyotish skill method is not bound into the system prompt for jyotish-vedic-astrology`（两次 attempt 各一条）。
+  2. 同一 runId 的 `[agent-observability]`：`toolCalls: []`、`modelStepCount: 0`、`inputTokens: 0`、`outputTokens: 0`、`run.total durationMs: 69`、`retryCount: 1`、`errorCode: runtime_contract_incomplete`。**模型从未被调用**，整轮 69 毫秒结束。
+  3. 代码对应：`jyotishSkillBoundProcessor`（`skill-binding.ts:143-153`）在输入处理阶段断言系统提示里含 `BOUND_METHOD_MARKER`（`<jyotish-skill name="...">`），缺失即 `abort()`。`jyotishSkillMethodBlock` 只在 `jyotishInstructions`（本命，`index.ts:21`）里插值；`windowJyotishInstructions`（`index.ts:176-190`）从未包含它，而 `getWindowJyotishAgent`（`index.ts:198`）照样 `...jyotishSkillBinding()`。
+  4. 时间线：处理器由 `d04fc30b`（2026-08-18）引入；窗口 Agent 由 `9958e00a`（2026-08-21）新建，**诞生时就带绑定、不带方法块**。因此申报时段路线自 2026-08-21 起每轮必败，已持续约四周。
+- 为什么没被发现：`abort()` 被翻译成与「模型没调工具」相同的公开码 `runtime_contract_incomplete`，与 BUG-922/923/937 的现象完全同名。BUG-937 的记录写的是「本命与申报时段两条路线每一轮都失败」，本命线被 `required` 的修复救活，窗口线的这条根因从未被触及，却因为现象消失一半而被当作同一件事结案。测试侧也没有「凡 attach `jyotishSkillBinding()` 的 Agent，其 instructions 必须含 marker」这条源码合同。
+- 修复：见 `docs/tasks/TASK-window-consult-contract-20260918.md`。要点：窗口指令注入带 marker 的方法块（不能直接照抄本命块，它带 Level 2 报告骨架与本命口径）；补源码合同测试；处理器 abort 给出独立可见错误码，不再与合同未完成同码。
+- 验证：待实现。
+- 防复发：待实现。
 - 关联记录：BUG-205、BUG-214、BUG-922、BUG-923、BUG-937、BUG-938
-- 复发自：BUG-923（`auto` 不保证调用这一条在 BUG-937 修复后回归）
+- 复发自：无（与 922/923/937 同现象、不同根因；那三条均未覆盖窗口 Agent 的提示词装配）
 - 修复版本：待发布