diff --git a/TASK-rectification-adopt-flow-fix-20260903.md b/TASK-rectification-adopt-flow-fix-20260903.md
new file mode 100644
index 00000000..5a525bb5
--- /dev/null
+++ b/TASK-rectification-adopt-flow-fix-20260903.md
@@ -0,0 +1,93 @@
+# 任务书 · 采用流程修复单:采集期出口兜底、「改选」可点、开场题不占 education、核对题年份持久化(2026-09-03)
+
+基线:`origin/staging` `35e5781e`(`TASK-rectification-adopt-flow-20260902.md` 的实现,BUG-497~500)。本任务书是对该实现 review 后的修复单,**不改 `35e5781e` 已定的形态**(公开 `can_adopt` 按 session_outcome 收紧、accept 409、核对题沿用持久化 questionId、卡归出卡消息、状态条承接),只修 1 个 P1 和 3 个 P2。
+
+## 0. Review 结论摘要
+
+`35e5781e` 门禁全绿(tsc / lint 0 错 / 1109 测试 fail=0),两个 P0 的修法与任务书一致。但收紧公开 `can_adopt` 之后,**非终止轮出口检查还在看内部 `canAdopt`**,会把一种此前靠"漏出的采用卡"兜住的状态变成真正的死角;另外三处是形态没做完或副作用。
+
+## 1. P1 · 采集期"无题、无卡、无出口"
+
+**位置**:`frontend/src/lib/rectification-agentic/v9/answer-choice.ts` `inspectNonTerminalTurnExit`(行号线索 ~992–1013,按符号名定位)。
+
+**现象(静态推演)**:`satisfied` 的最后一项是 `decision.canAdopt`(内部能力位)。当 `session_outcome = collect_evidence`、内部 `canAdopt = true`、`buildMethodFollowupPlan` 的 `next_followup` / `deferred_followup` 都为 null(题库耗尽)时:
+
+1. `persistNextInterviewIfIdle` 走到 `if (!followup) return { persisted:false }`,不建题;
+2. `ensureNonTerminalTurnExit` 因 `decision.canAdopt` 判 `satisfied = true`,**不调用 `persistExhaustionCollect` 兜底**;
+3. 公开 `can_adopt` 现在为 false → 前端不出采用卡;`showCollectStop` 依赖活跃采集题 → 「先这样」也不出;
+4. 用户只剩空 composer,随便发一句话再跑一轮回到同一状态。
+
+`35e5781e` 之前这个状态会漏出采用卡(就是 BUG-497 的现象),所以没人碰到过死角;现在门关了,出口必须补上。
+
+**修法**:
+
+1. `inspectNonTerminalTurnExit` 的 `satisfied` 把 `decision.canAdopt` 改成 `publicCanAdopt(decision)`(从 `core/rectification-decision` 导入)。语义:只有**用户在界面上真的能采用**时,"没有下一问"才算满足;否则走 `persistExhaustionCollect`(它建的题自带「先这样」,`answerChoice` 的 stop 路径会把 outcome 推到 `provisional_range_user_stopped`,公开 `can_adopt` 随之打开)。
+2. `persistNextInterviewIfIdle` 里 `shouldSkipFollowupPersist({ canAdopt: decision.canAdopt, ... })` 同步改成 `publicCanAdopt(decision)`。现有 nextAction 白名单已保证采集/区分/holdout 不会跳过持久化,这一改只是让"跳过持久化、改出 adopt 旁白"与公开门一致,不得出现"旁白说可以采用、界面却没卡"的分叉。
+3. 确认 `persistExhaustionCollect` 在 `collect_evidence` + 内部 `canAdopt = true` 下能返回一道题(`exhaustionSpokenCollectFollowup` 若也为 null,则至少给 `occupation` 兜底题——现有逻辑已有,验证即可)。
+
+**测试**(`tests/rectification-adopt-flow-fix-20260903.test.ts` 新建):
+- 构造 dossier:`sessionOutcome = collect_evidence`、内部 `canAdopt = true`、无 active focus、题库耗尽(evidence 覆盖所有 collect 域或 declined 全部)。断言 `ensureNonTerminalTurnExit` 返回 `persisted = true`,写入的 focus `intent = collect_method_evidence` 且 `projectCurrentQuestion(focus).kind === "collect_spoken"`,并有 `rectification_nonterminal_exit_repaired` warn。用 fake accounting,不需要真实环境。
+- 对照:`sessionOutcome = adopt_representative`(`publicCanAdopt = true`)同样条件下 `satisfied = true`、不建题(保留既有语义)。
+
+## 2. P2-a · 状态条「改选」是死的
+
+**位置**:`rectification-agentic-chat.tsx` 状态条 `改选`(~1501);`offerSectionRef`(~439、~1438)赋了 ref 但没有任何 `scrollIntoView` 调用。
+
+**修法**:
+1. 改成 ``,onClick:`offerSectionRef.current?.scrollIntoView({ block: "center", behavior: "smooth" })`,并给该消息一次 `rectification-message-flash`(globals.css 加一个 600ms 的背景闪烁 keyframe,复用现有 `.rectification-message-entry` 的色板)。
+2. `showSelectionCards` 为 false(出卡消息还没重建,或 `readonly`)时不渲染「改选」。
+3. `globals.css` `.rectification-adopt-status__link` 补 button reset(去边框/背景、光标 pointer、焦点环沿用 `.rectification-candidate` 的样式)。
+4. 测试:源码锁 `rectification-adopt-status__link` 出现在 `