merge origin/staging into report chart render branch

Keep BUG-607 after 602–606 and retain both 09-09 changelog entries.

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

docs/BUG_HISTORY.md

@@ -9334,6 +9334,86 @@
 - 复发自：无
 - 修复版本：待发布
 
+## BUG-602 | 时间轴宽度按差值算，卡片与报告按含两端算
+
+- 状态：resolved
+- 首次发现：2026-09-09
+- 最近更新：2026-09-09
+- 影响面：`rectification-timeline-scale.ts` 区间读数 `widthLabel`、`frontend/DESIGN.md` §10
+- 用户现象：同一屏上时间轴写的宽度比三列卡和验证报告少 1 分钟。例如区间 04:51–04:59 条上写「8 分钟」、卡上写「9 分钟」；05:07–05:09 条上写「2 分钟」；整天窗口写「23 小时 59 分」。
+- 触发条件：分钟阶段已有 `credible_range`，或时段阶段轴铺满整天窗口。必现。
+- 根因：`widthLabel` 用 `timelineDurationLabel(bandEnd - bandStart)`，少算两端都计入的那一分钟。BUG-593 已把交付报告与三列卡定为含两端分钟数；任务书示例「05:07–05:09 · 2 分钟」是差值口径，首版时间轴照抄了。
+- 修复：改为 `timelineDurationLabel(bandEnd - bandStart + 1)`。整天 00:00–23:59 显示「24 小时」，单分钟显示「1 分钟」。DESIGN.md §10 示例改为「05:07–05:09 · 3 分钟」。
+- 验证：`frontend/tests/rectification-timeline-20260909.test.ts`（含两端宽度表：04:51–04:59 → 9 分钟、05:07–05:09 → 3 分钟、04:51–04:53 → 3 分钟、单分钟 → 1 分钟、整天 → 24 小时）；与 `frontend/tests/rectification-delivery-report-facts.test.ts` 的 `width_minutes === 3` 同一形状。
+- 防复发：时间轴读数必须与报告/卡片同一套含两端分钟数；禁止再把 `bandEnd - bandStart` 当宽度。
+- 相关记录：BUG-593
+- 复发自：无
+- 修复版本：`92e3d5e7`
+
+## BUG-603 | 被排除的分钟到不了客户端，时间轴空心点画不出来
+
+- 状态：resolved
+- 首次发现：2026-09-09
+- 最近更新：2026-09-09
+- 影响面：`rectification-candidate-result.ts`、`rectification-timeline-scale.ts`、`rectification-agentic-chat.tsx` 的 `timelineView` 候选来源
+- 用户现象：DESIGN.md §10 写「被排除的点留在原地变空心、不消失」；真实会话里答完一题后那些分钟从条上消失，剩下的全是实心。看不到刚才那一答排掉了哪几分钟。
+- 触发条件：分钟阶段已有推断层、至少淘汰过一个候选。必现。
+- 根因：`inference-adapter.ts` 投影只保留 `status !== "eliminated"` 的候选；时间轴把 `candidateResult.candidates.map(time)` 当点，再按是否落在区间带内判 in/out。到达客户端的点都在带内，全是实心；被淘汰的分钟根本不在列表里。测试里的 `["out","in","in","in","out"]` 是合成输入，不是这条数据路径。
+- 修复：`RectificationCandidateResult` 增加只读 `inferenceMarks: [{time, eliminated}]`，从 `decisionReceipt.inference_state.candidates` 的 `time` / `status` 解析（组件不读原始 receipt）。`state = status === "eliminated" ? "out" : "in"`，不再按点是否落在带内判断。没有 `inference_state` 时退回引擎候选全部实心。
+- 验证：`frontend/tests/rectification-timeline-20260909.test.ts`：推断层 9 个候选、7 个 eliminated、可信区间 04:51–04:53 → 9 个点、7 空心 2 实心；再淘汰 1 个 → 8 空心 1 实心，key 不变。`frontend/tests/rectification-candidate-result.test.ts`：有 `inference_state` 时解析出全集，无则 `[]`。聊天源码合同：`timelineView` 读 `inferenceMarks`，不读 `decisionReceipt`。
+- 防复发：时间轴标记必须来自推断层候选全集；禁止再用引擎 active 投影或带内位置当 in/out。空心/实心只看 `status === "eliminated"`。
+- 相关记录：BUG-560、DESIGN.md §10
+- 复发自：无
+- 修复版本：`92e3d5e7`
+
+## BUG-604 | 开场不讲做法、一次只收一件，同一批经历被拆成多轮计费
+
+- 状态：resolved
+- 首次发现：2026-09-09
+- 最近更新：2026-09-09
+- 影响面：`buildOpeningBrief`、`GENERIC_COLLECT_QUESTION`、`jyotish-birth-time-rectification@10.0.19` OpeningPolicy、口述开场正文
+- 用户现象：开场不说当前窗口和最后会给什么，也不点出可以讲哪些方面；题干只请人说一件，一条消息里的多件经历被拆成多轮，每轮都要重算。
+- 触发条件：新建生时校正、进入开场采集。
+- 根因：opening brief 和 Skill OpeningPolicy 禁止领域清单、禁止一次说完；题干带年份例子。产品决定推翻该口径：列领域不列年份，一条消息可以报多件。
+- 修复：brief 写入当前搜索窗口与 intake 来源、做法三句要点、六类领域。开场正文不合格时服务端换成模板。首题仍是 `collect:other:*`，题干改为「先说你最容易想起的一两件，年月大概就行」。批量写入路径仍是 `rectification-record-evidence-batch`。Skill 10.0.19。只报一件走既有逐领域采集，不插入「还有吗」追问轮。
+- 验证：`frontend/tests/rectification-v9-agent.test.ts`（opening brief、落库正文替换）、`frontend/tests/agent-voice-copy-contract.test.ts`（开场模板与六类）、`frontend/tests/rectification-spoken-collect.test.ts`（三件已确认领域不再被逐个追问；单事件开场下一问为逐领域采集且正文不含「还有吗 / 别的吗」）、`frontend/tests/rectification-server-focus.test.ts`（GENERIC 题干）。
+- 防复发：开场落库正文必须 ≤4 句、至少五类领域、不含四位年份。不得要求先准备材料。不得把具体年份写进开场。不得因只报一件就插入追问轮或重复开场邀请。
+- 相关记录：BUG-488、BUG-558
+- 复发自：无
+- 修复版本：`aa7ccb30`、`1453fb16`
+
+## BUG-605 | 口述采集只能打字「没有」，没有「记不清」，也不知道可以跳过
+
+- 状态：resolved
+- 首次发现：2026-09-09
+- 最近更新：2026-09-09
+- 影响面：`rectification-agentic-chat.tsx` composer-wrap、`applyCollectFocusDenial`、`isCollectSkipUtterance`、采集回执文案
+- 用户现象：采集题只有输入框。想说这方面没有或这题记不清时，不知道可以跳过；打字「没有」才能走拒答。
+- 触发条件：`collect_spoken` 焦点激活且未 busy。
+- 根因：BUG-595 删掉输入框上方「先这样」后没有替代采集快捷回答。产品不要示例骨架条，只要「没有 / 记不清」。
+- 修复：composer-wrap 内两个 44px 次要按钮，类名 `rectification-collect-reply`，不复用 `rectification-step-state`。「没有」与打字「没有」同一 POST，走 declined，回执「记下了，这方面先跳过。」「记不清」走 skipped，回执「记下了，这题先放着。」精确这两句不调模型。skipped 领域本会话不再采集；采用后核对仍可碰到 skipped，不碰 declined。
+- 验证：`frontend/tests/rectification-spoken-collect.test.ts`（按钮只在 collect_spoken、精确「没有 / 记不清」短路分类器、skipped 不再采集、reverse-verify 仍可碰）。
+- 防复发：采集快捷回答不得画成「先这样」，不得用 `rectification-step-state`。不得在回答条预填年份。
+- 相关记录：BUG-546
+- 复发自：无
+- 修复版本：`aa7ccb30`
+
+## BUG-606 | 每轮气泡太长：方法句、领先落后、价值评价叠在正文里
+
+- 状态：resolved
+- 首次发现：2026-09-09
+- 最近更新：2026-09-09
+- 影响面：`chat-message-content.tsx`、`consultation-run-timeline.tsx`、`composeChoiceNarration`、`trimEvidenceTurnBody`、`agent-run` 开场/证据守卫
+- 用户现象：助手气泡里除了记下经历，还写「本轮对照了…」、点选后「这段领先那段落后」，以及「对校正特别有用」之类评价。
+- 触发条件：证据轮或点选题答完后看助手正文。
+- 根因：方法句渲在气泡；旁白拼接 `explainScoreMovement`；证据轮只靠提示词，模型仍写三句加评价。
+- 修复：气泡不再渲染 `vargaSentence`，展开的活动时间线保留。点选旁白只有「已记录，范围没变。」或「已记录，范围收到 / 变为 A–B。」证据轮超过两句只留首句，并去掉「很有帮助 / 很有价值 / 很有分量 / 特别有用」。
+- 验证：`frontend/tests/rectification-varga-style-copy.test.ts`、`frontend/tests/rectification-answer-choice.test.ts`、`frontend/tests/rectification-v9-agent.test.ts`、`frontend/tests/rectification-collect-prompt.test.ts`、`frontend/tests/agent-voice-copy-contract.test.ts`（机器词表含「领先」「落后」）。
+- 防复发：用户可见旁白不得出现「领先」「落后」。证据轮落库不得含价值评价四词。方法句不得回到气泡正文。
+- 相关记录：BUG-545、BUG-585
+- 复发自：无
+- 修复版本：`aa7ccb30`
+
 ## BUG-607 | 长报告页分盘标题下没有图
 
 - 状态：resolved

docs/tasks/PROGRESS-rectification-conversation-economy-20260909.md

@@ -0,0 +1,58 @@
+# PROGRESS · 生时校正对话精简（2026-09-09）
+
+工作树：`.worktrees/rectification-conversation-economy-20260909`
+分支：`codex/rectification-conversation-economy-20260909`
+任务书：`docs/tasks/TASK-rectification-conversation-economy-20260909.md`
+基线：`origin/staging` @ `d9252516`（任务书写 aa499da1；本 worktree 从当时的 staging 头切出，含时间轴文档提交）
+
+本单状态：**待验收**。产品提交 `aa7ccb30`；单事件开场补丁见本文件后文 SHA。尚未 push，未合入 staging/main。未合时间轴兄弟单。
+
+未改：采用门、确认门、各道门槛、`page.tsx`、`use-conversation-scroll-anchor.ts`。未改时间轴兄弟单文件（`rectification-timeline-scale.ts` / `rectification-candidate-result.ts` / 时间轴测试 / DESIGN §10）。Skill 停在 **10.0.19**（live + 快照同步改 OpeningPolicy，不升版）。
+
+## 做了什么
+
+- **BUG-604 / 决策 1** `buildOpeningBrief` 写入当前搜索窗口（`candidate_range` HH:MM–HH:MM）与 intake 来源、做法三句、六类领域。开场正文不合格则换成 `openingSpokenBody`。首题仍是 `collect:other:*`，题干 `GENERIC_COLLECT_QUESTION` =「先说你最容易想起的一两件，年月大概就行。」不写具体年份、不要求先准备材料。批量写入仍走 `rectification-record-evidence-batch`；已确认领域不再被 `nextDatedCollectFollowup` 追问。
+- **BUG-604 追问补丁（`origin/staging` `54adb0d1`）** 邀请多件是降低门槛，不是要求。开场只报一件：batch 写一条、compare 一次、下一问仍是既有 `nextDatedCollectFollowup`（顺序不变）。不插「还有吗 / 还能想起别的吗」追问轮，也不重复开场邀请。第一道逐领域题干由服务端加一次 `FIRST_DATED_COLLECT_INVITE` =「想到别的也可以一起说。」（`invite_more_once`，只一次）。用户可见文案未出现「还有吗」。
+- **BUG-605 / 决策 2** `collect_spoken` 且未 busy 时，`composer-wrap` 内两个 44px 次要按钮，类名 `rectification-collect-reply`（不复用 `rectification-step-state`，无示例骨架条）。「没有」= 打字「没有」= declined，回执「记下了，这方面先跳过。」「记不清」= skipped，回执「记下了，这题先放着。」精确这两句不调模型。skipped 本会话不再采集；采用后 `remainingReverseVerifyProbes` 仍可碰到 skipped（`includeSkipped: false`）。
+- **BUG-606 / 决策 3** 气泡不再渲染 `vargaSentence`；展开的 `ConsultationRunTimeline` / `AgentActivityStatus` 保留。点选旁白只有「已记录，范围没变。」或「已记录，范围收到 / 变为 A–B。」证据轮 `stripQuestionSentences` 之后 `trimEvidenceTurnBody`：超过两句只留首句，去掉「很有帮助 / 很有价值 / 很有分量 / 特别有用」。
+
+## 三栏（被触碰断言）
+
+| 用例 | 原值 | 新值 | 理由 |
+| --- | --- | --- | --- |
+| Skill / `RECTIFICATION_SKILL_VERSION` | `10.0.18` | `10.0.19` | OpeningPolicy 与证据轮口径变更 |
+| 开场 brief | 「不要一次说完 / 不要举例」 | 窗口 + intake 来源 + 做法三句 + 六类领域 | BUG-604 推翻旧口径 |
+| 开场题干 | 带大学例子的 GENERIC | 「先说你最容易想起的一两件，年月大概就行。」 | BUG-604；不写年份 |
+| 开场落库 | 模型一句招呼原样落库 | 不合格则换成三句模板；≤4 句、≥5 类、无年份 | BUG-604 |
+| composer-wrap 采集 | 无按钮（先这样已删） | 「没有」「记不清」44px，`rectification-collect-reply` | BUG-605 |
+| 精确「没有 / 记不清」 | 进分类器 / 模型 | 采集焦点分支短路，`declined` / `skipped`，无 `runV9AgentTurn` | BUG-605 |
+| skipped 领域 | 未单独建模 | 本会话不再采集；reverse-verify 仍可碰 | BUG-605 |
+| 气泡 `vargaSentence` | `ChatMessageContent` 渲染 | 只在展开活动时间线 | BUG-606(a) |
+| 点选旁白 | 「X 领先，Y 落后」+ 范围从…收到 | 「已记录，范围没变 / 收到 / 变为 A–B。」 | BUG-606(b) |
+| 机器词表 | 无「领先」「落后」 | `MACHINE_VOICE_LEXICON` 含这两词（用户可见旁白禁） | BUG-606(b) |
+| 证据轮正文 | 2–4 句额度；模型三句原样落库 | 超过两句只留首句；去掉价值评价四词 | BUG-606(c) |
+| Agent 提示 | 「正文只做承接（2-4 句）」；「接下来我们继续」 | 「正文只做承接」+「证据轮正文只写一句复述」；题干作下一段 | BUG-606 |
+| 流式三句证据 | `answerText` 等于模型全文 | 落库首句，并以 `replace: true` 覆盖可见正文 | BUG-606 服务端裁剪 |
+| 只报一件后的下一问 | 未单独锁；有插追问轮风险 | 下一问 = 既有 dated collect（education 后是 family）；正文无「还有吗 / 别的吗」 | `54adb0d1`；邀请不是要求 |
+| 第一道逐领域题干 | 等于 `USER_COLLECT_QUESTION.*` | 末尾一次接「想到别的也可以一起说。」；第二道起不再接 | 不是独立追问轮 |
+| Skill 10.0.19 哈希 | `a21b33abbbe3a530d725b94719b57ff8417cfcb850c54b547d5c18e390ec3d2b` | `a68885d3cf2110ee456bff65210c60e6bef4da4ea45e2a790a5462fd6d7307c8` | OpeningPolicy 补单事件口径；版本不升 |
+
+## 测试
+
+- `frontend` `./node_modules/.bin/tsc --noEmit`：exit 0
+- `npm run lint`：0 errors / 108 warnings（仓库基线 warning，无新 error）
+- 任务书指定切片：`tests/rectification-*.test.ts` + `agent-voice-copy-contract.test.ts` + `skill-registry.test.ts`（排除 database）：**1066 tests / 1066 pass / 0 fail**（含新增「single confirmed domain opening goes to dated collect without a chase-more turn」）
+- Docker `database-rectification-*.test.ts`：本机未跑，记 blocked
+- 浏览器真人走查：browser MCP 可用但无打开的页、无登录态的 `collect_spoken` 会话，未点到「没有 / 记不清」。采集按钮与 44px、不复用 `rectification-step-state` 由 `rectification-spoken-collect.test.ts` 锁源码。本补丁只改题干后缀与路由，无新 UI。
+
+Skill 10.0.19 SHA256：`a68885d3cf2110ee456bff65210c60e6bef4da4ea45e2a790a5462fd6d7307c8`。live 树与 `versions/10.0.19` 一致，registry 哈希与 `computeSkillPackageSha256` 一致。
+
+## 偏离 / blocked
+
+1. 预检系统 Python 3.14、无 pytest、无 swisseph（ERR-078）。**不声称预检通过。** 远端可见性此前已核过。
+2. 本机主仓停在 `codex/minute-rectification-p0` 且有脏文件；未 checkout / reset / stash。本单只在本 worktree。
+3. `move_agent_to_root` 对子代理不可用；全程用本 worktree 绝对路径。
+4. `.venv` 是指向主仓的 symlink，不提交。
+5. `origin/staging` 在切出后超前（含 `54adb0d1` 任务书补丁、`d5972ef4` BUG-607）。只把 `54adb0d1` 的 §2.1 单事件口径摘进本 TASK；**不**取 BUG-607，不 merge staging，不 push。
+6. BUG_HISTORY BUG-604/605/606 修复版本：`aa7ccb30`（产品提交）。单事件开场补丁是新提交，不 amend。
+7. 点选旁白测试里，若下一问未能单独落库，服务端仍可能把采集题干接在「已记录，范围收到…」后面。断言改为前缀匹配，不把下一问挂载当成旁白模板的一部分。

docs/tasks/PROGRESS-rectification-timeline-fix-20260909.md

@@ -0,0 +1,58 @@
+# PROGRESS · 生时校正时间轴修复单：宽度含两端、空心点来自推断层（2026-09-09）
+
+工作树：`.worktrees/rectification-timeline-fix-20260909`
+分支：`codex/rectification-timeline-fix-20260909`
+任务书：`docs/tasks/TASK-rectification-timeline-fix-20260909.md`
+基线：`origin/staging` @ `d9252516`（任务书写 `724a1215`；本 worktree 按开工指令从当时 `origin/staging` 切出）
+
+本单状态：**待验收**。提交 `92e3d5e7`。未 push，未合入 staging/main，未声称生产部署。
+
+预检：本机 `python3 scripts/pre_work_check.py` 失败（系统 Python 3.14 无 pytest、无 swisseph，ERR-078）。不把预检失败写成门禁已过。前端用 worktree 里已有的 `frontend/node_modules` 符号链接。
+
+未改：二元编码、只读、固定条高、grid 行、transform-only、`use-conversation-scroll-anchor.ts`、`frontend/src/lib/rectification-agentic/v9/*`、Skill / `references/conversation-strategy.md`、composer-wrap / collect 按钮 / vargaSentence / opening / spoken copy。Skill 版本不变。
+
+## 做了什么
+
+- **BUG-602** `widthLabel = timelineDurationLabel(bandEnd - bandStart + 1)`，与 BUG-593 交付报告含两端分钟数同一形状。
+- **BUG-603** `RectificationCandidateResult.inferenceMarks` 从 `decisionReceipt.inference_state.candidates` 的 `time` / `status` 解析；组件只把该数组交给时间轴，不读 raw receipt。`state = eliminated ? "out" : "in"`，不再按点是否落在区间带内判断。无 `inference_state` 时引擎候选全部实心。
+
+`inferenceMarks` 在类型上是可选的：`parseRectificationCandidateResult` **每次都写出数组**（没有推断层则为 `[]`）。若做成必填，会迫使改 `tests/rectification-range-delivery-20260907.test.ts` 里的结果字面量——该文件不在本单所有权内。
+
+## 三栏 · widthLabel
+
+| 用例 | 原值 | 新值 | 理由 |
+| --- | --- | --- | --- |
+| 05:07–05:09 | `2 分钟` | `3 分钟` | 含 05:07、05:08、05:09 三分钟；与 DESIGN §10 / 报告口径一致 |
+| 04:51–04:59 | `8 分钟` | `9 分钟` | 含两端；与三列卡同一形状 |
+| 04:51–04:53 | `2 分钟` | `3 分钟` | 与 `rectification-delivery-report-facts.test.ts` 的 `width_minutes === 3` 同一形状 |
+| 05:07–05:07 | `0 分钟` | `1 分钟` | 单分钟窗口 |
+| 00:00–23:59 整天 | `23 小时 59 分` | `24 小时` | 1440 分钟；时段阶段尚未排除任何分钟 |
+| 04:56–05:20（放宽后） | `24 分钟` | `25 分钟` | 含两端 |
+| 00:30–01:30（跨午夜带） | `1 小时` | `1 小时 1 分` | 61 分钟，同一条 `+ 1` 规则 |
+
+## 三栏 · 标记改按 status
+
+| 用例 | 原值 | 新值 | 理由 |
+| --- | --- | --- | --- |
+| 合成 05:06…05:10，带 05:07–05:09，无 inferenceMarks | `["out","in","in","in","out"]`（按是否落在带内） | 全部 `"in"` | 无推断层时引擎候选全部实心，决策 2 |
+| 同上，05:08 在带内但 `eliminated` | 05:08 会被判 `"in"` | 05:08 `"out"` | in/out 只看 `status === "eliminated"`，不看带 |
+| 推断层 9 点、7 淘汰、带 04:51–04:53，引擎投影只有 2 个 active | 条上 2 个实心点 | 9 个点，7 空心 2 实心 | 客户端以前拿不到被淘汰分钟 |
+| 下一轮再淘汰 1 个 | 点消失或 key 重建 | 8 空心 1 实心，key 不变 | 空心留在原地，过渡不重建 |
+
+## 测试
+
+- `frontend` `./node_modules/.bin/tsc --noEmit`：exit 0
+- `npm run lint`：0 error / 108 warning（仓库既有 warning，无新增 error）
+- 指定切片 `tsx --test tests/rectification-timeline-20260909.test.ts tests/rectification-delivery-report-facts.test.ts tests/rectification-candidate-result.test.ts`：**39 passed / 0 failed**（时间轴 22、候选解析 13、交付报告事实 4）
+- 浏览器真人走查：无登录态，仍见 `docs/testing/rectification-timeline-20260909.md`；§4 第一条已改为「被排除的分钟变空心且不消失（数据来自推断层）」
+
+## 偏离
+
+1. 任务书基线写 `724a1215`；本 worktree 按开工指令基于当时 `origin/staging` `d9252516`。
+2. `inferenceMarks` 类型可选，解析器始终赋值。见上文。
+3. 跨午夜 00:30–01:30 读数从「1 小时」变为「1 小时 1 分」，任务书未点名，但是同一条含两端规则。
+4. 未改 `inference-adapter.ts`：active 投影仍只给卡片；时间轴改走推断层全集。
+
+## 环境缺口
+
+无登录态、无 Chrome、无 Docker。浏览器级空心点/贴底仍欠真实会话。不把合同测试写成已经看见真实像素。

docs/tasks/README.md

@@ -84,8 +84,8 @@
 | `TASK-api-not-configured-mislabel-20260904.md` | `PROGRESS-api-not-configured-mislabel-20260904.md` | 16 处路由把数据库瞬断（部署切换窗口）兜底翻译成 503「服务尚未配置」；改为仅配置错误用该文案，其余 `service_unavailable`，收敛为共享 helper | 已验收 | `5483649b`（BUG-542）；2 条子进程测试留 CI Node 22 复核 |
 | `TASK-rectification-ux-20260902.md` | `PROGRESS-rectification-ux-20260903.md` | 会话面空白假死与交互摩擦 | 已验收 | `d159f08e`（09-03 在新基线重做后合入，BUG-505～509） |
 | `TASK-rectification-timeline-20260909.md` | — | 常驻吸顶时间轴：轴锁**当前**搜索窗口并随放宽缩放、时段/分钟两套标记、候选点二元编码不分置信度（BUG-560 blocked）、无 hover（BUG-575）、只读不可采用。实现用第三个 grid 行而非 `position: sticky`，`useConversationScrollAnchor` 一行不改；条高固定是正确性要求；吸顶条只留区间与宽度两个元素 | 已验收通过；宽度口径与空心点两处未通过→修复单 | `ce91a0d2` |
-| `TASK-rectification-timeline-fix-20260909.md` | `PROGRESS-rectification-timeline-fix-20260909.md` | 时间轴修复单：宽度读数改含两端分钟数（与 BUG-593 报告/卡片一致）；标记改读推断层候选全集，被淘汰分钟留在原地变空心（客户端投影只含 active，DESIGN §10 描述在真实数据下画不出） | 待执行 | `codex/rectification-timeline-fix-20260909`（BUG-602～603） |
-| `TASK-rectification-conversation-economy-20260909.md` | `PROGRESS-rectification-conversation-economy-20260909.md` | 对照竞品后产品拍板三条：开场三句讲做法 + 一次收多件（推翻 opening brief「不要一次说完/不举例」与 SKILL L52）；采集题「没有 / 记不清」按钮（不做示例骨架条）；每轮只留一句（方法句进活动记录、点选旁白去领先落后、证据轮正文一句复述 + 服务端裁剪）；Skill 10.0.19 | 待执行 | `codex/rectification-conversation-economy-20260909`（BUG-604～606） |
+| `TASK-rectification-timeline-fix-20260909.md` | `PROGRESS-rectification-timeline-fix-20260909.md` | 时间轴修复单：宽度读数改含两端分钟数（与 BUG-593 报告/卡片一致）；标记改读推断层候选全集，被淘汰分钟留在原地变空心（客户端投影只含 active，DESIGN §10 描述在真实数据下画不出） | 待验收 | `92e3d5e7`（BUG-602～603） |
+| `TASK-rectification-conversation-economy-20260909.md` | `PROGRESS-rectification-conversation-economy-20260909.md` | 对照竞品后产品拍板三条：开场三句讲做法 + 一次收多件（推翻 opening brief「不要一次说完/不举例」与 SKILL L52）；采集题「没有 / 记不清」按钮（不做示例骨架条）；每轮只留一句（方法句进活动记录、点选旁白去领先落后、证据轮正文一句复述 + 服务端裁剪）；Skill 10.0.19 | 待验收 | `aa7ccb30`、`1453fb16`（BUG-604～606） |
 
 ### 聊天主链路与首页
 
@@ -150,6 +150,7 @@
 | --- | --- | --- | --- | --- |
 | `TASK-upstream-sync-20260903.md` | `PROGRESS-upstream-sync-20260903.md`、`PROGRESS-upstream-capabilities-20260903.md` | 上游快照推进到 `a6f47abd`、引擎三方合并、health 三窗 / VedAstro REST 桥 / 专业报告导出 / 新字段接聊天与报告 / 校正解冻三项 | 已验收 | 0/1/2/4/6：`45d13258`、`f2241463`、`734d2059`；3/5/7：`c2f23131`～`6063c1f7`（BUG-514）。staging 已部署 `6063c1f7`。修复单 `4ee79210` 已验收 |
 | `TASK-upstream-sync-fix-20260903.md` | `PROGRESS-upstream-sync-fix-20260903.md` | 非原生主题恢复 `degraded`、finance Yogi/D11/confidence cap、模板注册表引用、VedAstro/MCP finance 路由与 quick CORE 扩列 | 已验收 | `4ee79210`（BUG-515）；staging health 已到该 SHA；十主题 e2e 合同全对，Python 红 90→69 无新增 |
+| `TASK-upstream-sync2-20260909.md` | — | 上游活跃分支 `b9a0ef8f`（未进 main）：婚恋三层触发模型（punarphoo / event_class_split 进证据链）+ 十套条件大运接 full reading 与长报告时间系统表；快照锁推进；Skill 6.9.16；不取 shadbala profile / PL9 用户版 / 校正泄漏项 | 待领取（串行在 `TASK-report-chart-render-20260909` 之后） | BUG-608 起 |
 
 ## 命名与归档
 

docs/tasks/TASK-upstream-sync2-20260909.md

@@ -0,0 +1,135 @@
+# TASK · 上游同步二（婚恋三层触发模型 + 条件大运族）— 2026-09-09
+
+- 基线：`origin/staging` @ `d5972ef4`（2026-09-09）。开工前 `git fetch origin --prune`，以远端为准。
+- 上游：`/workspace/yinduzhanxing`，源分支 **`origin/codex/add-birth-time-rectification-skill`** @ `b9a0ef8f`（2026-09-09 01:36 +0800，比 `origin/main` `a6f47abd` 多 155 提交，**未进 main**）。本仓快照锁仍是 `a6f47abd`（`references/upstream/yinduzhanxing/source-manifest.json`）。
+- 分支：`codex/upstream-sync2-20260909`，worktree `.worktrees/upstream-sync2-20260909`。
+- **串行**：`TASK-report-chart-render-20260909.md` 也改 `scripts/jyotish_engine.py`（`_render_south_chart` 一处）与 `CHANGELOG.md`。本单排在它**之后**：领取时若它已合入 staging 就以新 staging 为基线；若未合入，本单先做不碰 `render_pl9_markdown` 的任务 0–2，任务 3 的报告表格改动等它合入后 rebase 再做。
+
+## 1. 现状实证
+
+上游这条分支 09-03 以来做了三类事，逐条核过（`git diff --stat origin/main origin/codex/add-birth-time-rectification-skill`，638 文件 +77,465/−2,939，其中 references/docs 研究台账占九成）：
+
+| 类别 | 上游落点 | 本仓现状 | 本单取舍 |
+| --- | --- | --- | --- |
+| **婚恋触发三层模型**（CHANGELOG v6.9.15，2026-09-04） | `scripts/punarphoo.py`（新，102 行）、`scripts/relationship_analysis.py` +220、`scripts/dasha_calculator_enhanced.py` +54、`mcp_server.py` +59、`references/technique_registry.json` +40（`punarphoo` 项）、`references/yoga_rules.json` +50、`references/event_judgment_marriage.md` +65、`references/strict-workflow-router.md` +44、`tests/test_punarphoo_observation.py`（154 行）、`tests/test_mcp_strict_workflow_relationship.py` +24 | `relationship_analysis.py`、`yoga_rules.json`、`event_judgment_marriage.md`、`strict-workflow-router.md` 与上游 main **字节一致**（可直接覆盖）；`dasha_calculator_enhanced.py` 三方合并 0 冲突；`mcp_server.py` 三方合并 2 冲突；`technique_registry.json` 是本仓自己的 89 项注册表，只能手加条目 | **取**（任务 2） |
+| **条件大运族**（10 套 + 子周期 profile） | 新模块 `shodashottari / dwadashottari / panchottari / satabdika / shastihayani / chaturshitisama / dwisaptatisama / shattrimshatsama / tribhagi / niryaana_shoola_dasha.py` + `source_bounded_child_periods.py`（共 ≈1,700 行，纯计算，只互相 import，不读 references JSON）；`cmd_full_reading` 里 `birth_info_for_alt_dasha` 新增 5 个键并循环调用 10 套；PL9 大运表 104–120 行；29 个测试文件 | 本仓 `cmd_full_reading`（`jyotish_engine.py` L15096；alt-dasha 块 L16309–16340）只跑 Yogini / Ashtottari / Kala Chakra；`_native_dasha_master_families`（L2639）只映射 5 族；本仓旧 `conditional_dashas.py` 有 dwisaptati / shattrimsa / dwadashottari 的早期实现但没接进 full reading | **取**（任务 3）。上游是经 `professional_parity_closure.py`（本仓没有，+1,360 行研究模块）接 PL9 的，本仓走自己的 `_native_dasha_master_families` |
+| Shadbala Dig / Chesta 可选 profile | `scripts/shadbala.py` +122（`raman_luminary_zero`、`raman_inferior_planet_assignment`、`raman_wrapped_0_60`，默认 profile 不变）、api_server / MCP 加 `dig_profile` 参数、十几个 `shadbala_mercury_*` 研究脚本 | `shadbala.py` 三方合并 **7 冲突**；这些 profile 全是 Raman 例题 / PyJHora parity 探针，生产默认值不变 | **不取**。产品面零变化，合并成本高 |
+| PL9 用户版 `reader_main`（`_render_pl9_user_markdown`） | 把 `blocked`→「待补」、`parameter_sensitive`→「参考」，删含 PyJHora / schema / 审计 的行 | 违反本仓真话边界（报告页 `blocked` / `conflict` 标签必须可见，`frontend/DESIGN.md` Personal report reader） | **不取** |
+| 年运北印 SVG（`annual_north_indian_renderer.py`）、年运 Tajika / Mudda / saham 扩展 | 服务端 SVG | 图盘已决定前端自绘（`TASK-report-chart-render-20260909.md`） | 不取 |
+| Narayana / Rashi dasha 显式合同（`rashi_dasha_explicit_contract.py`、`narayana_dasha.py` +59、`drig / lagna_kendradi / navamsha / shoola_dasha.py`） | Visti Larsen 源冻结研究 | 本仓 `narayana_dasha.py` 有商业改动，与上游 main 已分叉 | 不取；PROGRESS 记一句 |
+| 校正：`_known_case_regression_hint`、「lock yn-1993 ayanamsa calibration baseline」、`active_rectification_candidates.py`、`/api/active_rectification_candidates` | 答案泄漏模式 + 候选差异合同 | 本仓已定性为泄漏（`TASK-upstream-sync-20260903.md` 硬红线 3）；split-hash / 分歧面板已覆盖候选差异需求 | **不取** |
+| `_render_pl9_user_markdown` 之外的 `render_pl9_markdown` 25 个 hunk、`write_pl9_pdf(edition)`、api_server +207 | PDF 版式与 MCP 报告入口 | 本仓报告是 Markdown 直渲，api_server 距增长上限只剩 67 行（11296 / 11363） | 不取 |
+
+三方合并干跑（base = 上游 main `a6f47abd`，ours = `origin/staging`，theirs = 分支）：`jyotish_engine.py` 整文件 13 冲突——但本单**不整文件合并引擎**，只搬 `cmd_full_reading` 的两个 hunk（都在本仓 L16309 附近、无冲突区域）；`mcp_server.py` 2 冲突（L50 import 区、`_maybe_attach_vedastro_evidence` 附近的岁差参数改动，后者不取）；`dasha_calculator_enhanced.py` 0 冲突。
+
+## 2. 差距（为什么值得做）
+
+1. 婚恋问题现在走 `jyotish_api_server.py` `_compute_relationship`（L7829）→ `analyze_relationship(planets_for_analysis, asc_sign)`（L7838，**没有传 `dasha_info`**，虽然咨询路径 L5429 已把 `_thematic_dasha_info` 放进 body），再由 `_derived_marriage_evidence`（L5519）把 `spouse_status_yoga` 与我方自己的 `relationship_timing`（`_compute_relationship_timing_evidence` L7861，DK/UL 线）写进证据链。`analyze_relationship` 里的 `timing` 只有一条「Venus/Jupiter/Moon 大运 → 感情活跃」，等于把心动、成对、领证三件事合成一句「婚恋机会」——上游 09-04 审计的假阳性根因就是这个；本仓因为没传 `dasha_info`，这句目前既不会出现、也不会被三层模型替代。上游改法把 `analyze_relationship` 输出加了 `event_class_split`（`romantic_activation` 看 5L / 7H 月亮 / Punarphoo；`relationship_formation` 看 7L / DK / UL；`legal_marriage` 看 Venus / DK / UL；只认 MD/AD，PD 记 `pd_hits` 不升格），这层本仓一行都没有。
+2. 长报告「时间系统证据状态」表（`render_pl9_markdown` 内 `_family_status_row`，L4027 定义、L4043–4047 五次调用；families 为空时 L4019 的 fallback 只喂 5 个键）只有 5 族。条件大运族每张盘通常只有 1–3 套适用，适用的那几套是正规 BPHS 内容，报告里现在完全没有。
+
+## 3. 决策记录（产品负责人 2026-09-09 拍板「需要第二份任务书」）
+
+| 决策 | 内容 |
+| --- | --- |
+| D1 | 取婚恋三层模型全部代码与参照文档；`punarphoo` 进注册表为 `partial / observation_only`，`prediction=not_claimed`，**永远不得**改写 `dominant_label=legal_marriage`。 |
+| D2 | 取 10 套条件大运 + `source_bounded_child_periods`，接进 `cmd_full_reading` 与 `_native_dasha_master_families`；报告表格里适用的显示 `executed / parameter_sensitive`，不适用的显示 `not_applicable`（附条件），出错的显示 `blocked`。**不**接 `professional_parity_closure.py`。 |
+| D3 | 快照锁推进到分支提交 `b9a0ef8f`，`source-manifest.json` 的 `boundary` 注明来源是非 main 分支；镜像策略 v2 不变（只镜像根 SKILL.md）。 |
+| D4 | Shadbala profile、PL9 用户版、年运渲染、Narayana 合同、校正三件：本轮不取（理由见 §1）。 |
+| D5 | 上游 AGENTS.md §8「MD/AD/PD 日期只许走引擎、禁止手写 DASHA_ORDER」不改本仓 AGENTS.md（那是产品负责人的文件），改写进商业 `SKILL.md` 路由段与咨询 prompt 的 relationship 硬约束行。 |
+| D6 | 商业 Skill 版本 bump `6.9.15 → 6.9.16`（SKILL.md 正文有改动）；新增 `skills/jyotish-vedic-astrology/versions/6.9.16/`，不改 6.9.15。 |
+
+不推翻既有红线。`TASK-upstream-sync-20260903.md` 硬红线 3（校正泄漏不取）、4（咨询响应契约只增不改）继续有效。
+
+## 4. 硬红线
+
+1. **咨询响应契约只增不改**：`/api/consultation_workflow` 与 `/api/relationship` 现有键路径、类型不变；`analyze_relationship` 只新增 `event_class_split` 与 `timing[].event_class`，原 `timing[].dasha / note` 键保留。任务 0 的 golden 逐键比对。
+2. `scripts/jyotish_api_server.py` **净增 ≤ 10 行**（当前 11296，上限 11363）。婚恋证据项构造放新模块 `scripts/relationship_event_class_evidence.py`，api_server 只加一行调用。
+3. 不整文件合并 `jyotish_engine.py` / `mcp_server.py`；按 hunk 搬，PROGRESS 列每个 hunk 的取舍。
+4. Punarphoo 与心动层只能出现在 `secondary_context` / 观察级证据里；任何把 `romantic_activation` 命中写成「会结婚」「领证窗口」的文案都不许，`frontend/docs/VOICE.md` 口径对照。
+5. 条件大运不得进入 `_calc_dasa_convergence` 的多系统交叉投票（保持 Vimshottari + Chara + Yogini 三系统不变），也不得进入校正打分（`rectification_*` 一个文件都不碰）。
+6. 注册表新条目商业状态按 09-03 规则：网页路径实际执行的才可写 `partial`，否则 `research_only_blocked`；条件大运 10 项因 full reading 会执行且报告会显示 → `partial`，`claim_boundary` 写「条件适用性 + 子周期 profile 为 PyJHora 等分法，未做多引擎 parity」。
+7. 不带任何 `references/research/**`、`references/oracle/*_2026_09_*.json` 研究台账进本仓；上游测试里 import 这些路径的用例不搬。
+8. 隐私：上游测试若含真实生日（分支里有 `yn-1993`、`1993-04-17` 样本），搬过来时换成公开名人或虚构日期。
+9. 前端不动（婚恋证据项走现有 evidence 渲染）；若发现必须动前端，停下来写 PROGRESS。
+
+## 5. 任务分解
+
+### 任务 0 · 基线快照
+
+- 在 `.worktrees/upstream-sync2-20260909` 用真实引擎跑三份 golden 存 `tests/golden/upstream_sync2/`：(a) `/api/relationship` 响应（公开名人案例，含 `dasha_info`）；(b) `/api/consultation_workflow` 婚恋问题响应的 `evidence_snapshot`；(c) `pl9-export` Markdown 里「时间系统证据状态」表。
+- 记录开工测试数：`.venv/bin/python -m pytest tests -q -x --co | tail -1`、`npm test` 总数。
+
+验收：三份 golden 进仓库；PROGRESS 记录命令。
+
+### 任务 1 · 快照推进
+
+- `scripts/import_yinduzhanxing.py --source /workspace/yinduzhanxing --source-commit b9a0ef8f… --dry-run` 在干净 worktree 跑，再 `--apply`；manifest 输出到 `references/cross_project_contract/imports/commit-b9a0ef8f….json`；`source-manifest.json` 更新 `source_commit / source_git_tree / boundary`（注明 `branch=codex/add-birth-time-rectification-skill, not on main`）。
+- `references/upstream/yinduzhanxing/SKILL.md` 镜像为上游 6.9.15（与 main 只差版本号两行）。
+
+验收：`tests/test_cross_project_contract*.py` 绿；manifest `privacy_scan.status == pass`；`sync_ledger.json` 追加一行。
+
+### 任务 2 · 婚恋三层触发模型
+
+1. 直接覆盖（与上游 main 字节一致的四个文件）：`scripts/relationship_analysis.py`、`references/yoga_rules.json`、`references/event_judgment_marriage.md`、`references/strict-workflow-router.md`，取分支版本。
+2. 新增 `scripts/punarphoo.py`；`scripts/dasha_calculator_enhanced.py` 三方合并（0 冲突）。
+3. `mcp_server.py` 只搬三处：`from punarphoo import detect_punarphoo`、`present["punarphoo"] = detect_punarphoo(...)`、`_collect_strict_evidence` 里 `romantic_activation` 观察块与 `secondary_context` 两项、`missing_evidence` 白名单加 `"punarphoo"`。**不搬**岁差改 `Optional[None]` 与 `_pl9_ayanamsa_selection_required_response`（本仓岁差已按 profile 传）。
+4. `references/technique_registry.json` 手加 `punarphoo`（字段照上游条目，`version` 写 `6.9.16`）；`references/oracle/commercial_skill_truth_overlay.v1.json` 加 `punarphoo: status=partial, claim_boundary="observation_only; not marriage; holdout not passed"`；计数断言（`tests/test_capability_evidence_pool.py` 的 `89 capability entries`、README 徽章、`tests/test_readme_badges.py`）改为新值，PROGRESS 三栏说明。
+5. `_compute_relationship` L7838 改为 `analyze_relationship(planets_for_analysis, asc_sign, dasha_info=body.get('dasha_info') if isinstance(body.get('dasha_info'), dict) else None)`（只在传了 `dasha_info` 时输出 `event_class_split`，`/api/relationship` 旧调用方响应不变）。新模块 `scripts/relationship_event_class_evidence.py`：`build_event_class_evidence(relationship: dict, theme_evidence) -> list[dict]`，把 `event_class_split` 变成 1–3 条 `_theme_evidence` 形状的证据项（`Romantic-activation`（观察级，`polarity=neutral`，`strength=weak`）、`Relationship-formation`、`Legal-marriage`（仅当 MD/AD 命中）），每条 `details` 带 `hits / pd_hits / claim_boundary`；`_derived_marriage_evidence` 末尾一行 `items.extend(build_event_class_evidence(relationship, self._theme_evidence))`。现有 `DK-UL-Dasha timing` 项保留不动。
+6. 商业 `SKILL.md` 路由段加两句：婚恋问题第一句冻结事件类（`romantic_activation / relationship_formation / legal_marriage`）；Dasha 日期只许引用引擎输出、不得自算 `DASHA_ORDER`。咨询 prompt 里 relationship 主题的硬约束行同步（找 `_build_chart_prompt_pack` 现有主题约束的落点，只加一行）。
+7. 测试：搬 `tests/test_punarphoo_observation.py`、`test_mcp_strict_workflow_relationship.py` 新增用例（去真实生日）；新增 `tests/test_relationship_event_class_evidence.py`：Moon–Saturn 7 宫合相 + Venus AD 的构造盘 → 出现 `Romantic-activation` 与 `Legal-marriage` 两条且前者 `strength=weak`；PD 命中不产生 `Legal-marriage`。
+
+验收：
+
+- [ ] `pytest tests/test_punarphoo_observation.py tests/test_mcp_strict_workflow_relationship.py tests/test_relationship_event_class_evidence.py tests/test_capability_evidence_pool.py tests/test_readme_badges.py` 全绿。
+- [ ] 任务 0 golden (a)(b) 逐键存在且类型一致；新增键只多不少。
+- [ ] `grep -rn "婚姻机会" scripts/relationship_analysis.py scripts/dasha_calculator_enhanced.py` 为 0 命中。
+- [ ] 快速门 `run_quality_gate.py --profile quick` 通过。
+
+### 任务 3 · 条件大运族接入 full reading 与长报告
+
+1. 新增 11 个模块（10 套 dasha + `source_bounded_child_periods.py`），取分支版本原样；模块内 `from scripts.source_bounded_child_periods import …` 的导入要兼容本仓两种运行方式（`scripts/` 直跑与包内），照 `professional_report_reference.py` `_load_engine` 的双路径写法。
+2. `cmd_full_reading`（本仓 L16309 `birth_info_for_alt_dasha`）：加上游 5 个键（`ascendant_longitude / sun_longitude / ascendant_sign_index / ascendant_hora_lord / navamsa_ascendant_sign_index / venus_rasi_sign_index / venus_navamsa_sign_index / tenth_lord_sign_index`，按上游 hunk 原样），Kala Chakra 之后加 Shastihayani 单独块与 9 套循环块；`pdf_edition` 分支不搬（本仓无该参数），子周期 profile 固定用 `PYJHORA_PARENT_SEEDED_EQUAL_SPLIT_PROFILE`。
+3. `_native_dasha_master_families`（L2639）mapping 加 10 个键（`tribhagi / tribhagi_40 / shodashottari / dwadashottari / dwisaptatisama / shattrimshatsama / panchottari / satabdika / chaturshitisama / shastihayani`）；`_native_dasha_family_status`（L2650 调用处）识别模块返回的 `execution_status == 'not_applicable'`，映射为 `status='not_applicable'` 且 `reason` 带适用条件文字；`_family_status_row`（L4027）加 `not_applicable` 分支（现在会把它当 blocked 走 L4039）。
+4. `render_pl9_markdown` 「时间系统证据状态」表：`_family_status_row` 之后按上游 104–120 编号顺序加 10 行；`not_applicable` 显示为 `调用状态=not_applicable`、`结论强度=—`、边界写条件（例如「Shodashottari：需上升在太阳 Hora 且白分 / 月亮 Hora 且黑分」）；`executed` 一律 `parameter_sensitive`。L4019 的 fallback mapping 同步加键。
+5. `scripts/consultation_engine_field_bridge.py`（L273 附近）与 `scripts/commercial_skill_truth.py` 的模块列表：新 10 个模块**不进**咨询 bundle（聊天不变），只进报告；PROGRESS 写明。
+6. 注册表加 10 项（`status=partial`，`user_visibility=expert_audit`，`commands=["full-reading"]`，`output_paths=modules.<key>`）；overlay 同步；计数断言随任务 2 一起改。
+7. 测试：搬上游 `tests/test_<family>_dasha.py` 10 个（去真实生日；`*_pyjhora_*_replay.py` 依赖研究 JSON 的不搬）；新增 `tests/test_full_reading_conditional_dashas.py`：公开名人盘 full reading 后 `modules` 含 10 个键、每个键要么有 `periods` 要么 `execution_status in {not_applicable, blocked}`；报告表格行数 = 5 + 10（+ Year Lord）。
+
+验收：
+
+- [ ] 上述测试全绿；`tests/test_full_report_quality_gate.py`、`tests/run_all.py` 不退。
+- [ ] 任务 0 golden (c) 表格原 5 行文字不变，只在其后新增行。
+- [ ] `_calc_dasa_convergence` 调用参数不变（git diff 里该调用零改动）。
+- [ ] `pl9-export` 真实案例耗时增幅 ≤ 20%（PROGRESS 写前后秒数）。
+
+### 任务 4 · 记录与发布件
+
+- `docs/BUG_HISTORY.md`：不是 Bug 修复，不占编号；但 `_compute_relationship` 原「Venus/Jupiter/Moon 大运 = 婚恋机会」的假阳性按 §5 规则登记一条 `resolved`（编号见 §8），关联上游审计结论。
+- `CHANGELOG.md`：「婚恋问题分心动 / 成对 / 领证三层作答；长报告时间系统表新增十套条件大运；Skill 6.9.16」。
+- `skills/jyotish-vedic-astrology/versions/6.9.16/` 由 `scripts/skill_release_manifest.py` 规则生成，`scripts/skill_release_package.py` dry-run 通过。
+- `docs/tasks/PROGRESS-upstream-sync2-20260909.md`：hunk 取舍表、冲突解决表、测试数前后、不取项清单。
+- `docs/testing/upstream-sync2-20260909.md`：真人清单——staging 上问一句「我什么时候会结婚」，回答必须分层且不给 PD 级月份；生成一份长报告，时间系统表可见新行。
+
+## 6. 让步顺序
+
+1. 任务 3 第 4 步的表格「条件文字」可先只写 `not_applicable`（条件文案后补）。
+2. 任务 3 第 7 步的 10 个上游单测可先搬 5 个（Shodashottari / Dwadashottari / Panchottari / Satabdika / Tribhagi），其余写进 BLOCKED.md。
+3. 任务 2 第 6 步的 prompt 硬约束行（保留 SKILL.md 改动）。
+4. **不可砍**：任务 0、任务 1、任务 2 第 1–5 / 7 步、任务 3 第 1–3 / 5 / 6 步、任务 4。
+
+## 7. 开工前置命令
+
+```bash
+git -C /workspace/Jyotisha status -sb | head -1
+git fetch origin --prune
+git worktree add -b codex/upstream-sync2-20260909 .worktrees/upstream-sync2-20260909 origin/staging
+cd .worktrees/upstream-sync2-20260909
+git -C /workspace/yinduzhanxing fetch origin --prune && git -C /workspace/yinduzhanxing rev-parse origin/codex/add-birth-time-rectification-skill   # 须为 b9a0ef8f…；若上游又推了，记录新 SHA 并重跑 §1 的 diff --stat
+python3 scripts/pre_work_check.py --remote-timeout 8 --command-timeout 45         # §9 预检（涉及远端同步）
+.venv/bin/python scripts/import_yinduzhanxing.py --source /workspace/yinduzhanxing --source-commit <SHA> --dry-run --output /tmp/claude-1000/sync2-dryrun.json
+.venv/bin/python -m pytest tests/test_full_report_quality_gate.py tests/test_capability_evidence_pool.py -q   # 基线
+```
+
+## 8. BUG 编号起点
+
+`docs/BUG_HISTORY.md` 当前最大 `BUG-601`；602–606 已被两份校正任务书占用，`TASK-report-chart-render-20260909.md` 占 **607**。本单从 **BUG-608** 起（任务 4 的假阳性登记），开工时重新核对。

docs/testing/rectification-scenarios-20260907.md

@@ -154,3 +154,18 @@
 - 双轨若写出偏向分钟，必须落在卡片范围内，不得点名已经被答题淘汰的分钟
 - 若报告写某候选的 D9 / D10 上升，必须与 `sign_by_candidate` 一致，不得按换升时刻自行推算成下一座
 
+## 11. 开场一次报三件后不再被逐个追问；每轮正文一句
+
+资料：家人记得大概时间，钟点任意，范围「差不多准」。地点任意公开城市。虚构经历。
+
+开场后用一条消息说三件不同领域、带年月的事（例如上学、第一份工作、搬家）。另走一遍只说一件。之后继续采集。
+
+期望：
+
+- 开场正文不超过四句，点出升学、第一份工作、搬家、恋爱结婚、家里的大事、生病受伤中至少五类，不含具体年份
+- 这一条消息只触发一次候选比较，账本写入三件
+- 下一问不再是已经说过的那三个领域
+- 只报一件时也只比较一次，下一问是既有逐领域采集，正文没有「还有吗 / 还能想起别的吗」；第一道逐领域题干末尾可以有一次「想到别的也可以一起说」
+- 口述采集输入框上方有「没有」「记不清」，没有「先这样」
+- 每轮助手正文一句复述（可另接一句范围变化）；气泡里没有「本轮对照了…」，也没有「很有帮助 / 很有价值 / 很有分量 / 特别有用」
+

docs/testing/rectification-timeline-20260909.md

@@ -35,7 +35,7 @@ iOS Safari 与 Android Chrome 各走一次，在校正对话里点输入框唤
 
 需要一个「完全不知道出生时间」的 Case 才能走到时段阶段。
 
-- [ ] 开场（整天或 ±120）时：条上是否**不出现**分钟圆点，区间带铺满整条轴，读数写整个窗口的宽度（如「23 小时 59 分」）？
+- [ ] 开场（整天或 ±120）时：条上是否**不出现**分钟圆点，区间带铺满整条轴，读数写整个窗口的宽度（如「24 小时」）？
 - [ ] 选定时段后：轴是否重新对到新窗口，读数变小？
 - [ ] 进入分钟阶段后：候选圆点是否出现？
 - [ ] 触发一次放宽（吻合率低且代表分钟贴边缘，BUG-572）：轴是否向外扩，区间带**没有**被裁掉或溢出轴外？
@@ -43,11 +43,11 @@ iOS Safari 与 Android Chrome 各走一次，在校正对话里点输入框唤
 
 ## 4. 二元编码与只读
 
-- [ ] 答完一道区分题后，被排除的分钟是否**留在原地变成空心**而不是消失？
+- [ ] 答完一道区分题后，被排除的分钟是否**留在原地变成空心且不消失**（数据来自推断层）？
 - [ ] 所有圆点是否**一样大**？（不得有任何按可能性大小分级的迹象——BUG-560 状态是 blocked）
 - [ ] 鼠标悬停在条上任何位置：是否**没有**任何浮层、提示、文案变化？
 - [ ] 点击条上任何位置：是否**没有**任何反应？（采用只在交付卡上）
-- [ ] 条上是否只有两样东西：轴，和形如 `05:07–05:09 · 2 分钟` 的读数？不应出现计数、图例、阶段名、「已对照 N 件经历」或任何注脚。
+- [ ] 条上是否只有两样东西：轴，和形如 `05:07–05:09 · 3 分钟` 的读数？不应出现计数、图例、阶段名、「已对照 N 件经历」或任何注脚。
 
 ## 5. 跨午夜窗口