@sema-agent/client-core 0.77.1 → 0.77.2

package/dist/hitl/planReviewWire.js

@@ -1,41 +1,3 @@
-/**
- * ⇄ B7 批搬迁(2026-07-27,设计稿 §3 B7):cli `src/sema/planReviewWire.ts`(142 行)**整条进包**。
- *
- * 🔴 **`wireConfig()` 第七份收编闭合**:B6 的 `engineWireTarget.ts` 头注记着「本批搬入的是前六份;
- *    第七份 `planReviewWire` 不在 B6 范围,仍留壳内 —— 它是下一批的收编候选,别以为已经收干净了」。
- *    本批就是那一批:这里改用 `engineWireTarget()`,壳树 `grep -rn 'function wireConfig' src/sema/`
- *    的七份手抄至此**归零**(pure 门 B7 段有断言:壳树在场时命中数 = 0;缺席 ⇒ DEGRADED)。
- *
- * 🔴 其余搬迁差分(零行为变化):
- *   1. `logForDebugging` → `hostLog`。
- *   2. `await import('../utils/messageQueueManager.js').enqueuePendingNotification({...})`
- *      → `NotificationQueuePort.enqueueMetaPrompt`(B7 新增的**可选**方法 —— 既有宿主实现不破)。
- *      🔴 缺席后果不是「少个装饰」:模型永远不知道 plan 被批准/驳回后引擎跑出了什么结果,
- *      于是它在 approve 之后**原地不动**。所以缺席计 miss(`notificationQueuePortMisses()`),
- *      并保留壳原文的 try/catch fail-soft(投递失败绝不炸流)。
- *   3. `registerLocalQuestionResponder`/`publishQuestionFrame` → 包内 `liveQuestionStore`
- *      (B1 已搬,**同一个 module 台账**;两份实例 ⇒ 卡弹出来没人收答)。
- *
- * ── 以下为原文件的领域说明(逐字保留)────────────────────────────────────────────────────────
- *
- * planReviewWire — plan_review park 的壳侧审批闭环(core [508]③ 形状拍板 + [511]② 实证)。
- *
- * WIRE 全链(server 1.138 × core 1.257.4 探针逐字实证,probe-plan-final-frame.mjs):
- *   1. plan-mode turn 里模型调 ExitPlanMode → 引擎 park:done 帧 `status:"needs_review"` +
- *      `checkpointGate:{kind:"plan_review",reason:"ExitPlanMode"}` + `errorCode:"review.pending"`;
- *      plan 文本已由 ExitPlanMode tool_end 渲染在转录(fence 块),checkpoint 落 FileCheckpointStore。
- *   2. 壳(本模块,runStream done 分支调用)合成一个 QuestionFrame 借 AskUserQuestion overlay 弹
- *      审批卡(core 拍板:不新造 live question 帧,壳自绘)——合成 id `plan-review:<taskId>` 经
- *      liveQuestionStore 的 LOCAL responder 拦截,绝不会打到引擎的 /v1/questions(那里 404)。
- *   3. 决断 → POST /v1/assistant/tasks/:taskId/plan_review `{decision:"approve"|"reject"}`——
- *      resume 是 SYNC 驱动到终态的(实证 200 `{taskId,sessionId,status:"completed"}`,可能分钟级),
- *      所以 fire 后卡片即关,完成后经 enqueuePendingNotification 入队一个 isMeta turn:模型收到
- *      resume 终态,自然接续汇报(approve 后"继续干活"的 CC 体验由引擎侧 resume 已完成,这里是
- *      结果呈现)。reject 同构(引擎丢 plan 保持 plan 语境)。
- *
- * 挂账(诚实边界):approve 后壳本地的 plan-mode footer 徽章不自动退(CC 会退)——退 mode 的
- * app-state seam 不在本模块可达面,记 rc.47 接 REPL 层;engine 侧 handsReadOnly 已由 resume 处理。
- */
 import { publishQuestionFrame, publishQuestionFrameFor, registerLocalQuestionResponder, unregisterLocalQuestionResponder, hasLocalQuestionResponder, hasQuestionOverlayFor, } from '../liveQuestionStore.js';
 import { hostLog } from '../host.js';
 import { makeEngineWireClient } from '../engineWireSdk.js';
@@ -47,32 +9,14 @@ import { planReviewQuestionId, REOPEN_ID_TAIL } from './gateIdentity.js';
 import { notePlanReviewAnswered, notePlanReviewAnsweredFor, planReviewArmedKeyFor, registerArmedGateFor, waitForGateArmedFor, wasGateArmedFor, } from './armedGateRegistry.js';
 import { DEFAULT_SESSION_KEY } from '../sessionSlot.js';
 import { PLAN_REVIEW_GATE_KIND } from '../adapter/activeRunSelfHeal.js';
-// 0.60.0(engine ≥7.64.0 / sdk 8.4.0):终局/park 读数的单一读器。
 import { readRunTerminal, runTerminalGateKind } from '../runTerminal.js';
-/** resume 是 SYNC 驱动到终态的(可能分钟级)——原 raw fetch 无超时;SDK Transport 恒有每请求
- *  超时,取 6h 宽上界(诚实预算:超过它基本是引擎僵死,超时文案与网络失败同走 outcome 通知)。 */
 const PLAN_REVIEW_RESUME_TIMEOUT_MS = 6 * 60 * 60_000;
-/**
- * REF-CC-026:此前是 module-private 常量,唯一另一个消费者(cli `planReviewReopen.ts`)只能靠
- * 人眼手抄同步(头注写着「与 client-core planReviewWire 的原卡逐字一致」)——漂一个字节,判决就
- * 落到危险的默认臂(见下方 `planReviewDecisionFromAnswer` 的头注)。现在导出成唯一真源;cli 侧改
- * import 是后续跟车工单(壳仓文件域,不在本卡范围)。
- */
 export const PLAN_REVIEW_APPROVE_LABEL = 'Yes, approve and run the plan';
 export const PLAN_REVIEW_REJECT_LABEL = 'No, reject it (keep planning)';
-/**
- * 0.72.13 CC-46(engine ≥7.86.0 S-433;契约 §4c):三选卡的两个 Yes —— 对齐 CC `ExitPlanMode` 卡
- * 「Yes, and auto-accept edits」/「Yes, and manually approve edits」。只在**双闸**都过时才出三选卡(见 {@link planReviewCardOptions}
- * 的调用点):宿主声明这条任务是它自己用 `permissionMode:"plan"` 提交的(适用面读不到 wire)∧ 引擎版本证据 ≥7.86.0。
- */
 export const PLAN_REVIEW_APPROVE_AUTO_LABEL = 'Yes, and auto-accept edits';
 export const PLAN_REVIEW_APPROVE_MANUAL_LABEL = 'Yes, and manually approve edits';
-/** `permissionModeAfter` 的引擎地板(server 7.86.0;更老的 server 静默丢这个键 = 承诺了却不兑现)。 */
 export const PLAN_REVIEW_MODE_AFTER_MIN_ENGINE = Object.freeze([7, 86, 0]);
-/** 引擎版本串够不够新:三态 —— 读不出(缺席 / 非 x.y.z)⇒ `unknown`,**不折 supported**(没证据不许出三选卡)。 */
 export function versionSupportsPlanReviewModeAfter(v) {
-    // 🔴 **整串**匹配正式版 x.y.z(无前导零):预发布(7.86.0-rc.1 可能还没实现这一位)/ 尾随垃圾 / v 前缀 / 空白 一律 unknown ——
-    //    它们不是支持证据(异源对抗复审:前缀匹配曾把这些都放行,宿主声明为 true 时三选卡就出了,而老引擎静默丢键)。
     const mm = v ? /^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)$/.exec(v) : null;
     if (!mm)
         return 'unknown';
@@ -87,39 +31,20 @@ export function versionSupportsPlanReviewModeAfter(v) {
 }
 const APPROVE_LABEL = PLAN_REVIEW_APPROVE_LABEL;
 const REJECT_LABEL = PLAN_REVIEW_REJECT_LABEL;
-/** 老两选卡的标签集 = 判读口不给展示标签时的缺省读域。 */
 const LEGACY_TWO_CHOICE_LABELS = Object.freeze([PLAN_REVIEW_APPROVE_LABEL, PLAN_REVIEW_REJECT_LABEL]);
-/** 四个已知标签(只供**记账**口判「是不是一次决断性作答」,不驱动任何决断)。 */
 const ALL_KNOWN_LABELS = Object.freeze([
     PLAN_REVIEW_APPROVE_AUTO_LABEL,
     PLAN_REVIEW_APPROVE_MANUAL_LABEL,
     PLAN_REVIEW_APPROVE_LABEL,
     PLAN_REVIEW_REJECT_LABEL,
 ]);
-/**
- * REF-CC-026:三值判决(此前 `selected === APPROVE_LABEL ? 'approve' : 'reject'` 把「没读懂/没
- * 选」的第三种输入静默塌缩进危险的 reject 臂——overlay 的 dismiss/拒答语义是「送空 answers」,
- * 与用户真的点了 REJECT_LABEL 长得一模一样)。两个标签都做**显式**等值比对,任何第三种输入
- * (含 undefined)落 `'dismissed'`,由调用方决定是保持 park 还是显式当 reject 处理——本函数只
- * 负责如实分类,不替调用方做选择。
- */
-export function planReviewDecisionFromAnswer(answer, 
-/** 本次实际展示的那张卡的标签;不给 = 老两选(见 {@link planReviewChoiceFromAnswer})。 */
-shownLabels) {
+export function planReviewDecisionFromAnswer(answer, shownLabels) {
     const choice = planReviewChoiceFromAnswer(answer, shownLabels);
     if (choice === 'dismissed')
         return 'dismissed';
     return choice.decision;
 }
-export function planReviewChoiceFromAnswer(answer, 
-/**
- * 本次**实际展示**的那张卡的标签(`planReviewCardOptions(offer).map(o => o.label)`);只认其中的标签。
- * 🔴 **不给 = 老两选**:三选卡的两个 Yes 只有调用方显式说「我展示的是三选卡」才读得成批准 —— 缺省不许替老调用方
- *    悄悄扩大批准的输入域(异源对抗复审:重开腿恒两选,缺省放行时一个没展示过的 auto 标签会被投递成 approve)。
- */
-shownLabels = LEGACY_TWO_CHOICE_LABELS) {
-    // 🔴 这是一张**单选**卡,而其中一项在安全轴上(批准后放宽写征询):恰一题、恰一项才算作答。矛盾多选(`[auto, reject]`)/
-    //    多题 / 空 selected 一律 dismissed —— 此前只取 `selected[0]`,拒绝意图会被丢弃、放宽被执行(异源对抗复审 [high])。
+export function planReviewChoiceFromAnswer(answer, shownLabels = LEGACY_TWO_CHOICE_LABELS) {
     const answers = answer?.answers;
     if (!Array.isArray(answers) || answers.length !== 1)
         return 'dismissed';
@@ -127,7 +52,6 @@ shownLabels = LEGACY_TWO_CHOICE_LABELS) {
     if (!Array.isArray(picked) || picked.length !== 1)
         return 'dismissed';
     const selected = picked[0];
-    // 标签必须属于这次展示的卡:两选卡上不存在「auto-accept edits」,收到它 = 答的不是这张卡。
     if (typeof selected !== 'string' || !shownLabels.includes(selected))
         return 'dismissed';
     if (selected === PLAN_REVIEW_APPROVE_AUTO_LABEL)
@@ -140,7 +64,6 @@ shownLabels = LEGACY_TWO_CHOICE_LABELS) {
         return { decision: 'reject' };
     return 'dismissed';
 }
-/** 卡选项的**单源**:`offerModeAfter=false` ⇒ 老两选(逐字同旧);`true` ⇒ 三选(两个 Yes + No)。 */
 export function planReviewCardOptions(offerModeAfter) {
     const reject = { label: REJECT_LABEL, description: 'Discard this plan and stay in plan mode to refine it' };
     if (!offerModeAfter) {
@@ -152,34 +75,14 @@ export function planReviewCardOptions(offerModeAfter) {
         reject,
     ];
 }
-/**
- * 推代的**门控口**(A-024.4;#244 F1 上收,语义照壳现实现):只有**决断性**作答(approve/
- * reject 标签命中 —— {@link planReviewDecisionFromAnswer} 的官方三值分类)才消费当代 plan 门。
- * Esc/空答对原卡是 dismissal(arm 臂的 dismissed 分支不驱动 decidePlanReview,checkpoint 仍
- * pending)—— 那时推代会把「被关过」翻成「首见」,恰是 A-024.4 在最常见路径(Esc 关卡)上要
- * 保住的区分。消费方 = 宿主 overlay 的 answerAndRelease(respond 成功后调 —— 它是 responder
- * 之外**第二条**决断可见点,原卡与重开卡两条通路对同一张卡各报一次,`notePlanReviewAnswered`
- * 按完整 questionId 去重恰推一代);包内 responder 走 {@link notePlanReviewAnswered} 直报
- * (它们没有 dismissed 臂会到达记账行)。
- */
 export function notePlanReviewAnsweredIfDecisive(questionId, answer) {
     notePlanReviewAnsweredIfDecisiveFor(DEFAULT_SESSION_KEY, questionId, answer);
 }
-/** W1 带 key 变体。 */
 function notePlanReviewAnsweredIfDecisiveFor(sessionKey, questionId, answer) {
-    // 记账口:两种卡的任一已知标签都算决断性作答(这里不投递决断;投递侧各自按**自己展示的卡**校验标签)。
     if (planReviewDecisionFromAnswer(answer ?? { answers: [] }, ALL_KNOWN_LABELS) === 'dismissed')
         return;
     notePlanReviewAnsweredFor(sessionKey, questionId);
 }
-/**
- * done 帧的 plan_review park 形状(结构性读,别的终局一律 false)。
- *
- * 🔴 0.60.0(engine ≥7.64.0 / sdk 8.4.0):判据从退役的两个平面键(`status:"needs_review"` +
- *    `checkpointGate.kind`)换成带标因由 `terminal.paused.gate.kind`,读法单源
- *    {@link readRunTerminal}。门种仍**逐字只认 `plan_review`**(不顺手放宽到 `dry_run_review` /
- *    `needs_review`):本臂驱动的是那一个 resume verb,放宽等于把别的门送进一个它答不了的入口。
- */
 export function isPlanReviewPark(result) {
     const read = readRunTerminal(result);
     if (read === null || read.kind !== 'paused')
@@ -189,45 +92,24 @@ export function isPlanReviewPark(result) {
     const taskId = result?.taskId;
     return typeof taskId === 'string' && taskId.length > 0;
 }
-/**
- * REF-CC-027:已武装未消解的 taskId 去重集(与 `HitlBridge`/`liveQuestionStore` 同款「进程内单例
- * 承重不变量」——见 `docs/refactor/p1-scan/singleton-manifest.json` 登记)。durable re-attach 会把
- * 同一个 `done{needs_review}` 帧再送一遍(与 askGateWire 的 `decidedGates` 同一族问题);此前
- * `armPlanReviewApproval` 对同一 taskId 的重复调用会**再注册一次** responder(旧的注销函数被整个
- * 丢掉),第二次注册会覆盖 `localResponders` 里的条目——若第一张卡此刻还没答,它的 unregister
- * 闭包会变成一个指向"已被覆盖"槽位的悬空引用。这个集合让重复 arm 直接幂等短路,不再产生第二次
- * `registerLocalQuestionResponder` 调用。
- */
 const armedPlanReviewTaskIds = new Set();
-/**
- * 0.72.13 CC-46:这张已武装的卡**出的是不是三选卡**(两个 Yes 各带一档批准后模式)。与 {@link armedPlanReviewTaskIds}
- * 同生命周期(arm 写、决断性作答 / arm 失败清);重放重呈读它,保证同一张卡前后两次呈现选项一致。缺席 = 老两选。
- */
 const offerModeAfterByTask = new Map();
-/** 测试钩:清掉武装态(不动 liveQuestionStore 本身,那边有自己的 reset)。 */
 export function _resetArmedPlanReviewsForTest() {
     armedPlanReviewTaskIds.clear();
     offerModeAfterByTask.clear();
 }
-/* 合成 questionId 的唯一铸口:A-028.3 起收编进 `gateIdentity.planReviewQuestionId`(公面导出,
- * 壳侧重开腿从此 import 同一铸口,不再手抄字面)。本文件只 import,不再自铸。 */
-/** 首次 arm 的题面正句。 */
 const ARM_QUESTION = 'The plan is ready for review. Approve it and start the implementation?';
-/** 重开腿的题面正句(点明「这张卡就是占住会话的那件事」;标签/选项与首呈同源)。 */
 const REOPEN_QUESTION = 'This plan is still waiting for your review — it is what is holding this session. Approve it and start the implementation?';
-/** 题面唯一构造点 —— 首次 arm、重放重呈、重开三处共用,标签/选项描述不许各写一份。 */
 function planReviewQuestions(question, offerModeAfter = false) {
     return [
         {
             header: 'Plan review',
             question,
-            // 选项单源 `planReviewCardOptions`:老两选逐字同旧;三选只在 arm 的双闸都过时出(重开腿恒老两选 = 批准不带键 ⇒ default)。
             options: planReviewCardOptions(offerModeAfter),
             multiSelect: false,
         },
     ];
 }
-/** 审批卡的发布口 —— 首次 arm 与「重放 arm 重新弹卡」共用同一份(canonical 身份)。 */
 function publishPlanReviewCard(taskId) {
     publishQuestionFrame({
         type: 'question',
@@ -235,87 +117,32 @@ function publishPlanReviewCard(taskId) {
         questions: planReviewQuestions(ARM_QUESTION, offerModeAfterByTask.get(taskId) === true),
     });
 }
-/**
- * Arm the approval card for a parked plan_review (call with the RAW done.result). Returns true when
- * armed (live path + shape matched, INCLUDING the idempotent "already armed" short-circuit — see
- * REF-CC-027 above); false = caller renders the terminal as usual. Fail-soft: any error inside must
- * never break the stream drain.
- */
-export function armPlanReviewApproval(result, sessionKey, 
-/**
- * 0.72.13 CC-46:`submittedInPlanMode: true` = 宿主声明「这条任务是我用 `permissionMode:"plan"` 提交的」(只读起步)。
- * 🔴 这件事**读不到 wire 上**(契约 §4c:两种任务产出同一张卡),所以只能由提交方声明;不声明 / false ⇒ 老两选卡、决断体不带键。
- * 声明了还要过第二道闸:本进程 caps 缓存里的引擎版本 ≥7.86.0(更老的 server 静默丢这个键 = 卡上承诺了却不兑现)。
- */
-opts) {
+export function armPlanReviewApproval(result, sessionKey, opts) {
     let armedTaskId;
     try {
         if (!isPlanReviewPark(result))
             return false;
-        // 🔴 **非默认槽 ⇒ 运行时 fail-closed**(异源对抗复审第六轮 [high] 采纳:「文档登记不能代替运行时
-        //    隔离」)。additive 第二参让 keyed 宿主**说得出**这条 park 属于哪个槽;库这边诚实回答
-        //    「这条链今天服务不了它」,而不是**默默按默认槽立卡、再按默认槽把决断发出去** ——
-        //    后者在「默认槽 + keyed 槽同时装配」的宿主上会把 B 会话的 approve/reject 带着**默认槽**的
-        //    baseUrl/token/principal 发出去(对端有同名任务就改错会话的状态,没有就 404 而原 run 继续
-        //    停在审批门)。整条链(卡注册 / 退役 / responder 台账 / decide)同批转 keyed 是 additive
-        //    公开面改动,归后续工单;在那之前**明确拒绝**比静默回落默认槽诚实。
-        //    ⚠️ 不传 / 传默认槽 ⇒ 与 0.44.0 逐字同(单会话宿主零受迫)。
         if (sessionKey !== undefined && sessionKey !== DEFAULT_SESSION_KEY) {
             hostLog('error', `planReviewWire: plan_review 卡未 arm —— 本链今天只服务默认会话槽,收到 sessionKey=${JSON.stringify(sessionKey)}。` +
                 '多会话宿主的 plan-mode 归后续工单(卡台账/responder/decide 需同批转 keyed);' +
                 '此处拒绝而不是回落默认槽 —— 回落会把这条会话的决断带着别的槽的 baseUrl/token/principal 发出去。');
             return false;
         }
-        // 🔴 design/285 批 3 的**显式裁定:plan 决策链两处 `engineWireTarget()` 本批豁免**(D7b 全量
-        //    清单里唯二不换的两处;设计稿 §1 明令「施工时显式裁入射程或豁免 + 理由」,不许静默漏)。
-        //
-        //    豁免的理由**不是**「它没有这个病」——它有:keyed 宿主上 plan 决断会走默认槽的 baseUrl /
-        //    token / principal。理由是**只换这一跳会造出一个新的自相矛盾**:整条 plan_review HITL 链
-        //    今天是默认槽单会话形 —— 卡的注册与退役按 `DEFAULT_SESSION_KEY`(下一行 `retireActiveReopen`
-        //    与 `liveQuestionStore` 的 responder 台账同键),`decidePlanReview` 又是从那张卡的 responder
-        //    里回调的。把 wire target 单独换成 keyed = 「按默认槽立卡、按 keyed 槽发决断」,比现状更坏
-        //    (现状至少两头一致地错在同一个槽上,一眼可见;半 keyed 形是两头不一致,只在多会话下现形)。
-        //    ⇒ 正确的做法是整条链(卡台账 + responder + wire)**同批**转 keyed,那是 additive 公开面
-        //    改动(`armPlanReviewApproval` 要收 sessionKey 并把它捎进 responder 闭包),归后续工单;
-        //    与本行下方那条「多会话宿主的 arm 路径归后续工单」是同一条欠账,不是两笔。
-        //    现状由常驻钉 `B3-P31/G18b` 钉住(装了 keyed 槽而默认槽为空 ⇒ 本腿仍判 offline),
-        //    防「悄悄换成 keyed」与「悄悄以为已经 keyed 了」两向。
         if (!engineWireTarget())
             return false;
         const { taskId } = result;
-        // 单活纪律(复审二轮,与 reopen 侧对偶):arm/重呈要发的 canonical 卡从此是这个 gate 唯一的
-        // 作答入口 —— 名下还在场的重开卡先退役(注销 responder + 撤帧)。不退役的话,durable 重放的
-        // arm 会在 fresh 重开卡还开着时再立一张 canonical 卡,双活双投递面从 arm 侧复发。
-        // (arm 臂是默认会话装配,退役也按默认键;多会话宿主的 arm 路径归后续工单。)
         retireActiveReopen(DEFAULT_SESSION_KEY, planReviewQuestionId(taskId));
         if (armedPlanReviewTaskIds.has(taskId)) {
-            // REF-CC-027:同一张卡还没消解就被重放的 arm 撞上——幂等,**不二次注册** responder。
-            //
-            // [2393] hitl-F3(2026-08-02):但「不二次注册」不等于「什么都不做」。旧码在这里只打一行
-            // debug 就 `return true`,于是这条短路成了一堵挡死重开路径的墙:
-            //   · `liveQuestionStore.ts` 的契约明写「dialog dismissed without answering ⇒ caller cleans
-            //     up」,而本模块**没有** dismiss/abort 腿 —— 用户 Esc 关掉卡(不作答)之后,武装态
-            //     一直是 true,responder 也一直挂着;
-            //   · 此后每一次 arm(durable re-attach 重放 / 409 撞上再开)都走这条短路:**一张卡都不弹**,
-            //     调用方拿到 true 于是也不渲终帧 —— 用户面静默挂住,plan 卡在 park 里没有任何出口。
-            // 修法按「还在不在」分两支,两支都不产生第二次 `registerLocalQuestionResponder`:
             if (hasLocalQuestionResponder(planReviewQuestionId(taskId))) {
-                // responder 还绑着 ⇒ 这张卡仍然可作答,只是可能已经不在屏上了。**重新弹一次**
-                // (同一个 questionId、同一份题面、同一个 responder):卡还开着的宿主只是收到一帧同形
-                // 的重绘,卡已经被 dismiss 的宿主则拿回了它的重开路径。
                 hostLog('debug', `planReviewWire: arm replayed — re-presenting the still-armed card for task ${taskId}`);
                 publishPlanReviewCard(taskId);
                 return true;
             }
-            // responder 不在了(被别的注册顶掉后注销 / 被单方面清理)⇒ 武装态是**陈旧**的。
-            // 复用它 = 弹一张没有任何人能收答的卡(比不弹更坏:它看起来能点)。丢掉陈旧记号,
-            // 往下走整条重新 arm —— 这正是 REF-CC-027 头注里那个「悬空引用」形的收尾。
             hostLog('debug', `planReviewWire: stale armed state for task ${taskId} (no local responder) — re-arming from scratch`);
             armedPlanReviewTaskIds.delete(taskId);
         }
         armedPlanReviewTaskIds.add(taskId);
         armedTaskId = taskId;
-        // CC-46 双闸:宿主声明 ∧ 引擎版本证据(读不出 ⇒ unknown ⇒ 不出三选卡)。
         const offerModeAfter = opts?.submittedInPlanMode === true &&
             versionSupportsPlanReviewModeAfter(engineCapString(engineWireTarget()?.baseUrl, 'version')) === 'supported';
         if (offerModeAfter)
@@ -324,28 +151,17 @@ opts) {
             offerModeAfterByTask.delete(taskId);
         const questionId = planReviewQuestionId(taskId);
         const unregister = registerLocalQuestionResponder(questionId, async (_id, answer) => {
-            // REF-CC-027:一次性 —— 首句就注销 + 清武装态(照 askGateWire 的 cleanup() 形)。
-            // liveQuestionStore.respondToQuestion 自身也是一次性取件(delete-before-invoke),这里是
-            // 第二道钉:武装态一清,同 taskId 才能重新正常 arm(证明 responder 真的落定了)。
             unregister();
             armedPlanReviewTaskIds.delete(taskId);
             const shown = planReviewCardOptions(offerModeAfterByTask.get(taskId) === true).map(o => o.label);
             const choice = planReviewChoiceFromAnswer(answer, shown);
             if (choice === 'dismissed') {
-                // dismiss/无法判读:诚实缺席优先于编造默认值(REF-CC-026)——不静默驱动 decidePlanReview,
-                // 卡的重开路径把决定权还给用户。呈现台账的键**不清**:同一张卡再被重开就是真「reopened」。
                 return { ok: true };
             }
             const decided = choice.decision;
-            // CC-46:只有三选卡的两个 Yes 带批准后模式;老两选的 Yes / No 不带 ⇒ 决断体不落键。
             const modeAfter = choice.decision === 'approve' ? choice.permissionModeAfter : undefined;
             offerModeAfterByTask.delete(taskId);
-            // A-024.4(#244 F1 起走分代):决断一经递交,这个门的呈现史就消费掉(当代键清 + 推代);
-            // 同 run 的**下一个** plan gate(approve 推进后引擎可再 park 一个新 plan)必须读回首见,
-            // 否则文案对一张从未呈现过的新卡说「reopened」。递交后决定未生效的形(RB-471 族)读回
-            // 首见只损失「reopened」一词 —— 首见文案零历史断言,诚实方向安全。
             notePlanReviewAnswered(questionId);
-            // fire-and-forget:resume 同步驱动到终态可能分钟级,不能挂住 overlay;结果经 queue 通知回来
             hostLog('debug', `planReviewWire: arm responder delivering ${decided} for task ${taskId} (path=arm)`);
             void decidePlanReview(taskId, decided, modeAfter);
             return { ok: true };
@@ -355,8 +171,6 @@ opts) {
         return true;
     }
     catch (e) {
-        // REF-CC-027:arm 本身失败(register/publish 抛)绝不能把 taskId 永久锁在武装态里
-        // ——那样这张卡再也无法被正常 arm 一次。
         if (armedTaskId !== undefined) {
             armedPlanReviewTaskIds.delete(armedTaskId);
             offerModeAfterByTask.delete(armedTaskId);
@@ -365,10 +179,6 @@ opts) {
         return false;
     }
 }
-/**
- * outcome 尾句的**唯一铸点**(给模型的下一步指令)。🔴 只有 `took_effect` 才许说「已批准并汇报做了什么 / 已拒绝」;
- * 其余三态一律不许出现把决断当成已生效的措辞 —— 那会让模型向用户汇报一件没发生的事。
- */
 export function planReviewOutcomeTail(taskId, decision, effect) {
     switch (effect) {
         case 'took_effect':
@@ -387,40 +197,16 @@ export function planReviewOutcomeTail(taskId, decision, effect) {
             return `Do not state the result as fact: tell the user the ${decision} was submitted but its effect could not be confirmed; TaskOutput("${taskId}") shows where the task stands.`;
     }
 }
-/** POST the decision; on settle enqueue an isMeta turn so the model reports the resume outcome.
- *  SDK 宪法迁移批:SDK 0.0.52 assistant.planReview verb(同 wire `POST /v1/assistant/tasks/:id/
- *  plan_review` 同 body {decision})——raw fetch 退役。错误模型:非 2xx 抛 APIError(message =
- *  server body.error 原文)→ 同款「HTTP <status> <error>」outcome 文案;网络失败走原「could not
- *  reach the engine」臂。 */
-/**
- * 投递口在飞集(0.73.1):同 taskId 的第二次 decide 在第一次 **POST 落地之前**到达 = 重复投递(下游定谳的 0.9 s 双 approve 形)。
- * 🔴 窗只到 POST 落地,**不盖**其后的状态回拉(最长 15 s)与 outcome 投递:引擎收下 approve 后可以立刻续跑又停一张新门,
- *    那张新门的作答是合法的第二次决断,回拉期间到达不许被吞(异源对抗复审 [high])。
- * 被闩住的那次:错误级留痕、不发第二条 meta prompt(第二条会让模型对用户汇报两次)。
- */
 const decideInFlight = new Map();
 let decideDispatchSeq = 0;
-/** 测试钩:清投递口闩。 */
 export function __resetPlanReviewDecisionLatchForTests() {
     decideInFlight.clear();
 }
-export async function decidePlanReview(taskId, decision, 
-/**
- * 0.72.13 CC-46(engine ≥7.86.0;契约 §4c):批准之后用哪一档。缺席 ⇒ 体逐字节同旧 `{decision}`。只配 approve、闭集两词 ——
- * 坏形本地拒(零 POST,outcome 如实说没送出去,不回显值)。引擎答 400 `request.field_conflict`(这条任务不是只读起步):
- * `default` 与缺席同义 ⇒ 去键重发恰一次;`acceptEdits` **不**重发(不静默降成逐次征询),outcome 说批准没生效。
- */
-permissionModeAfter) {
-    // REF-CC-025:此前 `cfg`/`client` 缺席各自 `return` 静默——卡已经对用户回了「收到」
-    // (armPlanReviewApproval 的 responder 早就 `return {ok:true}` 过了),但决断本身连一次网络
-    // 请求都没发出去,而模型/用户没有任何回程信号。两条早退现在都汇进同一条 outcome 管道(下方
-    // 唯一的 enqueue 调用点),不再是两条独立的静默 return。
-    // 0.73.1 投递口闩:在飞中的第二次 decide 直接拒(错误级留痕;不发第二条 meta prompt —— 那会让模型汇报两次)。
+export async function decidePlanReview(taskId, decision, permissionModeAfter) {
     if (decideInFlight.has(taskId)) {
         hostLog('error', `planReviewWire: decidePlanReview(${decision}) for task ${taskId} REFUSED — a decision for this task is already in flight (duplicate delivery latched)`);
         return;
     }
-    // 所有权 token:只有持闩的那次调用能放闩(异源对抗复审:旧调用回拉完成后的 finally 曾无条件 delete,把新调用刚取的闩删掉)。
     const token = {};
     decideInFlight.set(taskId, token);
     const releaseLatch = () => {
@@ -433,19 +219,12 @@ permissionModeAfter) {
         await decidePlanReviewInner(taskId, decision, permissionModeAfter, dispatchNo, releaseLatch);
     }
     finally {
-        releaseLatch(); // 没走到 POST 的早退路径(本地拒 / 无连接)也要放闩;幂等,持闩者才真放
+        releaseLatch();
     }
 }
-async function decidePlanReviewInner(taskId, decision, permissionModeAfter, dispatchNo, 
-/** **最终**一次 POST 落地(成功或失败;含 default 去键重发)那一刻调:闩窗到此为止。幂等。 */
-releaseLatch) {
+async function decidePlanReviewInner(taskId, decision, permissionModeAfter, dispatchNo, releaseLatch) {
     let outcome;
-    // 0.73.1:决断**有没有生效** —— 尾句按它选,不按 `decision` 无条件追加。此前 approve 恒追加「取续跑结果并汇报做了什么」、
-    // reject 恒追加「告知用户计划已拒绝」,于是「could NOT be sent」「did NOT take effect」的正文后面跟着一句让模型把没生效的
-    // 决断当成已生效去汇报的指令(同一段 meta prompt 自相矛盾)。缺省 = 未确认(任何一条路径忘了归类,都落在最保守的那一句上)。
     let effect = 'unconfirmed';
-    // 🔴 design/285 批 3 显式裁定:本处与 `armPlanReviewApproval` 同一笔豁免(理由逐字见那边)——
-    //    决断是从 arm 立的那张卡的 responder 回调进来的,槽键必须与立卡时同源,单换这一跳即两头不一致。
     const cfg = engineWireTarget();
     const badMode = permissionModeAfter !== undefined && (decision !== 'approve' || !isPlanReviewModeAfter(permissionModeAfter));
     if (badMode) {
@@ -472,7 +251,6 @@ releaseLatch) {
         }
         else {
             try {
-                // sdk 9.6.0 的 PlanReviewRequest 未声明 permissionModeAfter ⇒ 交集型加一可选位;缺席 = 键不落(体逐字节同旧)。
                 const mode = isPlanReviewModeAfter(permissionModeAfter) ? permissionModeAfter : undefined;
                 const reqBody = { decision };
                 if (mode !== undefined)
@@ -482,12 +260,9 @@ releaseLatch) {
                     body = await client.assistant.planReview(taskId, reqBody);
                 }
                 catch (e1) {
-                    // 400 request.field_conflict + 带了 default:default ≡ 缺席(契约:缺席 = 这一档)⇒ 去键重发恰一次,零语义损失。
-                    // 被这道门拒掉的请求一个字节的状态都不动(契约),同一次批准可原样重试。acceptEdits 不走这里(见下方 catch)。
                     const conflict = e1;
                     if (mode === 'default' && conflict?.status === 400 && conflict?.errorCode === 'request.field_conflict') {
                         hostLog('debug', 'planReviewWire: permissionModeAfter "default" refused as not applicable — re-sending the approval without the key (same meaning)');
-                        // 去键重发仍属**原决断**(400 明确没改状态)⇒ 闩不放,直到重发落地(异源对抗复审 [medium])。
                         body = await client.assistant.planReview(taskId, { decision });
                     }
                     else {
@@ -495,14 +270,9 @@ releaseLatch) {
                     }
                 }
                 finally {
-                    releaseLatch(); // 最终一次 POST 落地(成功 / 400 / 重发成败)⇒ 闩窗到此为止;其后的回拉与 outcome 不在窗内
+                    releaseLatch();
                 }
                 hostLog('debug', `planReviewWire: ${decision} → ok (dispatch #${dispatchNo}) ${JSON.stringify(body).slice(0, 200)}`);
-                // [2315]/[2316](#109,2026-08-02):decide 的 **2xx 不当终态** —— test 黑盒实测 reject 9/9
-                // 返回 200 而会话仍锁在同一 gate(core RB-471:重开兜底对 reject 腿恒真误触发)。这里回拉
-                // 一次任务状态,按真形分三路措辞;根因归 core/server,本腿是「对外动作回读验证」在产品面的
-                // 同款,上游修后仍有价值(approve 合法推进新 gate 的形也靠它说真话)。
-                // 回拉用**短超时**独立 client(15s):verify 腿挂住不该占用 decide 的 6h 宽预算。
                 let postStatus;
                 try {
                     const probe = makeEngineWireClient({
@@ -517,13 +287,9 @@ releaseLatch) {
                 catch (e) {
                     hostLog('debug', `planReviewWire: post-decide status re-pull failed (fail-soft): ${String(e)}`);
                 }
-                // 回拉失败时回落 decide 200 体自带的 status(次级来源;两者都缺=unverified,措辞如实降级)。
                 const effective = postStatus ?? (typeof body?.status === 'string' ? body.status : undefined);
                 if (effective === 'needs_review') {
                     effect = 'still_parked';
-                    // 决定没生效,仍锁原 gate。不渲「已处理」;真出路只有 approve 或 cancel(下一次提交撞 409
-                    // 时 activeRunSelfHeal 会把审批卡重开——这里不自动重弹卡,避免「刚拒绝又弹卡」的突袭感,
-                    // 决定权经卡的重开路径还给用户)。
                     outcome =
                         `The plan_review ${decision} returned HTTP 200 but the session is STILL locked on the same review gate ` +
                             `(post-decide status: needs_review). The decision did NOT take effect (known engine issue, RB-471 family). ` +
@@ -531,7 +297,6 @@ releaseLatch) {
                 }
                 else if (effective === 'suspended') {
                     effect = 'advanced';
-                    // 合法推进到新 gate(test [2315] ②形):不是「完成」,如实说下一张审批卡会跟上。
                     outcome =
                         `The plan was ${decision === 'approve' ? 'approved' : 'rejected'} and the task advanced to a NEW approval gate ` +
                             `(post-decide status: suspended) — the next approval card will surface it; this is not a completion yet.`;
@@ -541,27 +306,20 @@ releaseLatch) {
                     outcome = `The plan was ${decision === 'approve' ? 'approved and the parked task resumed to completion' : 'rejected (plan discarded)'} — final status: ${effective} (post-decide re-checked: task left the review gate).`;
                 }
                 else {
-                    // 复审 R1:正文也不许断言成功 —— 200 只证明引擎受理了请求,效果是什么本包此刻不知道。
                     outcome = `The plan_review ${decision} was accepted by the engine (HTTP 200) but its effect is unconfirmed — final status: unknown (post-decide verification unavailable). Do not treat this as ${decision === 'approve' ? 'an approval that resumed the task' : 'a discarded plan'}.`;
                 }
             }
             catch (e) {
-                // APIError 判型走 status duck-check(sseIdleTriage 同款纪律:双包时 instanceof 会分叉)。
                 const status = e?.status;
                 const refusedCode = e?.errorCode;
                 if (status === 400 && refusedCode === 'request.field_conflict' && permissionModeAfter === 'acceptEdits') {
-                    // CC-46:这条任务不是只读起步的(模型自选 plan 模式那种形)⇒ 引擎拒收「批准后自动接受编辑」。**不**静默降档重发:
-                    // 用户选的是「不再逐次征询」,悄悄换成「逐次征询」= 替他改了决定。引擎一个字节的状态都没动,计划仍在等。
                     hostLog('debug', 'planReviewWire: approve + acceptEdits refused (request.field_conflict) — NOT re-sent with a different mode');
-                    effect = 'still_parked'; // 契约:被这道门拒掉的请求一个字节的状态都不动 ⇒ 计划仍停在同一张门上,这一形能确定
+                    effect = 'still_parked';
                     outcome =
                         'The plan approval was NOT applied: the engine refused "auto-accept edits" for this task (it was not started read-only in plan mode, so that option does not apply). ' +
                             'Nothing changed engine-side — the plan is still waiting for review. Tell the user plainly, and that approving with "manually approve edits" will go through.';
                 }
                 else if (status === 404 && refusedCode === 'not_found.plan_review') {
-                    // 0.73.5:这道门已经不在了(早先的决断已生效,或已过期)。现场形:用户在一张**陈旧的重开卡**上作答 ⇒ 404;
-                    // 通用句「decision failed: HTTP 404 …」被模型读成「计划被拒 / 计划失败」,于是对用户说计划被拒并重新规划 ——
-                    // 而那份计划其实已批准并跑完。⇒ 明说这不是拒绝也不是失败,只是这次作答没有对象;效果态仍是 not_applied。
                     hostLog('debug', `planReviewWire: ${decision} → 404 not_found.plan_review (no pending plan review any more — an earlier decision likely settled it)`);
                     effect = 'not_applied';
                     outcome =
@@ -571,7 +329,6 @@ releaseLatch) {
                 else if (typeof status === 'number') {
                     const msg = e instanceof Error ? e.message : String(e);
                     hostLog('debug', `planReviewWire: ${decision} → ${status} ${msg.slice(0, 200)}`);
-                    // 4xx = 引擎明确拒收(状态没动);5xx / 其它 = 不知道引擎那头做到了哪一步 ⇒ 未确认
                     effect = status >= 400 && status < 500 ? 'not_applied' : 'unconfirmed';
                     outcome = `The plan_review decision failed: HTTP ${status} ${msg}`.trim();
                 }
@@ -581,10 +338,6 @@ releaseLatch) {
             }
         }
     }
-    // REF-CC-025:唯一的 enqueue 调用点(三条上游路径——cfg 缺席 / client 缺席 / 正常决断—— 都汇到
-    // 这里)。返回值此前被丢弃:`enqueuePlanReviewOutcome` 返回 `false` 意味着队列口没装或没实现
-    // `enqueueMetaPrompt`(notifications.ts 头注:「模型永远不知道 plan 被批准/驳回后引擎跑出了
-    // 什么结果」),这是与 HTTP 失败同等重量的静默丢失,必须留痕。
     try {
         const delivered = enqueuePlanReviewOutcome(`<plan-review-outcome>\n${outcome}\n${planReviewOutcomeTail(taskId, decision, effect)}\n</plan-review-outcome>`);
         if (!delivered) {
@@ -595,21 +348,10 @@ releaseLatch) {
         hostLog('debug', `planReviewWire: outcome enqueue threw: ${String(e)}`);
     }
 }
-/** 重开身份的进程内唯一尾缀(时基 + 随机段:两份包实例同时铸也不撞键 —— 撞键会被宿主 overlay
- *  的去重集吃掉帧,重开静默变 no-op;所以刻意不用模块级计数器)。 */
 function reopenIdSuffix() {
     return `${Date.now().toString(36)}${Math.random().toString(36).slice(2, 8)}`;
 }
-/**
- * 每个 `(sessionKey, canonicalId)` **至多一个在场的重开 responder**(复审 [high]:此前每次重开
- * 都新注册一个 responder 而不退役上一个 —— 重试/并发 409 会留下两张都能投递决断的活卡,
- * 一张 approve 一张 reject 就是两次相互冲突的状态变更请求)。铸新卡前:退役上一张的 responder +
- * 对它的帧 id 发 `question_complete` 撤卡;作答/退役后清账。
- * 🔴 模块级单例(singleton-manifest 登记):两份实例 ⇒ 各退各的,跨份的旧卡退役不掉 ——
- * 退化回修复前的重复活卡形。
- */
 const activeReopenResponders = new Map();
-/** 退役 `(sessionKey, canonicalId)` 名下还在场的重开 responder(撤帧 + 注销 + 清账)。 */
 function retireActiveReopen(sessionKey, canonicalId) {
     const key = `${sessionKey}\u0000${canonicalId}`;
     const prev = activeReopenResponders.get(key);
@@ -620,36 +362,23 @@ function retireActiveReopen(sessionKey, canonicalId) {
         prev.unregister();
     }
     catch {
-        // 注销钩自身的意外 throw 不许挡住新卡铸造(退役面 fail-soft,新卡才是用户的把手)
     }
     publishQuestionFrameFor(sessionKey, { type: 'question_complete', questionId: prev.questionId });
 }
-/** 测试钩:清空重开 responder 台账(跨用例状态)。 */
 export function _resetActiveReopenRespondersForTest() {
     activeReopenResponders.clear();
 }
 export function reopenPlanReviewCard(taskId, opts) {
     const receiptMs = opts?.presentationReceiptMs;
-    /** 回执模式下发布之后的收口(订阅必须**先于** publish:总线 handler 同步跑,快 overlay 的
-     *  登记可能发生在 publish 返回之前 —— 后订阅会错过已发生的回执)。 */
     const settleOnReceipt = (receipt, firstSight) => receipt.then((presented) => (presented ? { reopened: true, firstSight } : { reopened: false }), () => ({ reopened: false }));
     try {
         if (typeof taskId !== 'string' || taskId.length === 0) {
             return receiptMs === undefined ? { reopened: false } : Promise.resolve({ reopened: false });
         }
         const sessionKey = opts?.sessionKey ?? DEFAULT_SESSION_KEY;
-        // 诚实边界:请求方会话没有 overlay 订阅者(headless / 尚未挂载)⇒ 返回 false,调用方如实说
-        // 「没能重开」。overlay 在场答的是「有没有一个 UI 会收到这一帧」;检查按 sessionKey 走 ——
-        // 别的会话挂着 overlay 不等于本会话的卡有地方渲(复审 [high]:默认键硬走会把帧投进别人的面)。
         if (!hasQuestionOverlayFor(sessionKey)) {
             return receiptMs === undefined ? { reopened: false } : Promise.resolve({ reopened: false });
         }
-        // 🔴 **非默认槽 + 没有自带投递口 ⇒ 拒绝重开**(异源对抗复审第七轮 [high] 采纳)。本函数按传入的
-        //    `sessionKey` 在 B 槽发卡与记账,但**缺省 responder 投递走 `decidePlanReview`,而那一处固定读
-        //    默认槽的 `engineWireTarget()`** ⇒ 用户在 B 看到并点下去的 approve/reject 会带着 **A 的**
-        //    baseUrl/token/principal 出站(对端有同名任务就改错会话的状态,没有就 404 而 B 的任务继续锁死)。
-        //    arm 臂那道 fail-closed 覆盖不到这条 409/自愈重开入口 —— 两个入口必须同命。
-        //    ⚠️ 宿主自带 `deliverDecision`(它自己按槽投递)⇒ 放行,那时投递口不再是库内的默认槽管道。
         if (sessionKey !== DEFAULT_SESSION_KEY && opts?.deliverDecision === undefined) {
             hostLog('error', `planReviewWire: plan_review 卡未重开 —— sessionKey=${JSON.stringify(sessionKey)} 是非默认槽,` +
                 '而缺省决断投递口(decidePlanReview)今天固定打默认槽的 baseUrl/token/principal。' +
@@ -658,22 +387,14 @@ export function reopenPlanReviewCard(taskId, opts) {
             return receiptMs === undefined ? { reopened: false } : Promise.resolve({ reopened: false });
         }
         const canonicalId = planReviewQuestionId(taskId);
-        // 先查(firstSight)后记 —— 顺序决定判决正确性;台账按 sessionKey 分账,键 = **当代** plan 键
-        // (A-024.4 分代:0 代与 canonical 字节同形,决断消费后落新代 —— 恒定键会对同 run 的下一只
-        // plan 门谎报「被关过」)。
         const armedKey = planReviewArmedKeyFor(sessionKey, taskId);
         const firstSight = !wasGateArmedFor(sessionKey, armedKey);
         const mintFresh = opts?.mintFreshQuestionId !== false;
         if (!mintFresh && hasLocalQuestionResponder(canonicalId)) {
             hostLog('debug', `planReviewWire: reopen for task ${taskId} reusing the canonical responder (path=reopen-canonical)`);
-            // 重呈短路(与 arm 臂的重放短路同形):同一个 canonical 身份、同一份题面、同一个 responder。
-            // 卡还开着的宿主只是收到一帧同形重绘,卡已被 dismiss 的宿主拿回重开路径。
-            // 0.29.0 发包扫描门:本臂沿用 arm responder ⇒ opts.deliverDecision 不生效(JSDoc 成文例外),
-            // 传了就留痕 —— 静默吞注入口是契约不一致的形。
             if (opts?.deliverDecision !== undefined) {
                 hostLog('debug', `planReviewWire: reopen canonical-reuse branch for task ${taskId} ignores opts.deliverDecision (answers route through the existing arm responder — documented exception)`);
             }
-            // 先退役本会话名下还在场的**重开**卡(如此前走过 mintFresh 臂)—— 同一 gate 不留两张活卡。
             retireActiveReopen(sessionKey, canonicalId);
             if (receiptMs !== undefined) {
                 const receipt = waitForGateArmedFor(sessionKey, [canonicalId], receiptMs);
@@ -687,19 +408,11 @@ export function reopenPlanReviewCard(taskId, opts) {
             publishQuestionFrameFor(sessionKey, {
                 type: 'question',
                 questionId: canonicalId,
-                // 🔴 沿用 arm responder ⇒ 题面必须是**那张卡**的选项(三选 arm 后重绘成两选 = 屏上的 Yes 不在 responder 的读域里,点了不投递)。
                 questions: planReviewQuestions(ARM_QUESTION, offerModeAfterByTask.get(taskId) === true),
             });
             registerArmedGateFor(sessionKey, armedKey);
             return { reopened: true, firstSight };
         }
-        // 复审 [high] 单活纪律(两轮收紧):铸新卡前退役**全部**旧作答入口 —— 同一个 gate 至多一张
-        // 能投递决断的卡,两张都活着时一张 approve 一张 reject = 两次相互冲突的状态变更请求。
-        //   · 上一张重开卡:注销 responder + question_complete 撤帧(单活台账);
-        //   · canonical(arm)卡:question_complete 撤帧**且按 id 注销 responder**(二轮 [high]:
-        //     撤帧只是 UI 动作,表里的 responder 不死,在途的迟到作答仍能经它投递)。canonical
-        //     responder 死后,arm 重放走它自己的「陈旧武装态 ⇒ 整条重新 arm」自愈臂([2393] hitl-F3),
-        //     不会留下弹不出卡的死短路。
         retireActiveReopen(sessionKey, canonicalId);
         if (unregisterLocalQuestionResponder(canonicalId)) {
             hostLog('debug', `planReviewWire: reopen retired the canonical responder for task ${taskId} (single-active discipline)`);
@@ -709,45 +422,30 @@ export function reopenPlanReviewCard(taskId, opts) {
         hostLog('debug', `planReviewWire: reopen for task ${taskId} minting a fresh card ${questionId} (path=reopen-fresh)`);
         const deliver = opts?.deliverDecision ??
             ((tid, decision) => {
-                // fire-and-forget:resume 同步驱动到终态可能分钟级,不能挂住 overlay(arm 臂同姿势);
-                // 失败处置/结果回植由 decidePlanReview 自带的 outcome 管道承担。
                 hostLog('debug', `planReviewWire: reopen responder delivering ${decision} for task ${tid} (path=reopen-default)`);
                 void decidePlanReview(tid, decision);
             });
         const activeKey = `${sessionKey}\u0000${canonicalId}`;
         const unregister = registerLocalQuestionResponder(questionId, async (_id, answer) => {
-            unregister(); // 一次性(arm 臂同款):respond 侧 delete-before-invoke 之外的第二道钉
-            // 单活台账清账(只清**自己**的条目 —— 自己被更新的重开取代后,旧 responder 的迟到作答
-            // 不许把新卡的条目清掉)。
+            unregister();
             if (activeReopenResponders.get(activeKey)?.questionId === questionId) {
                 activeReopenResponders.delete(activeKey);
             }
-            // 本腿展示的恒是老两选 ⇒ 显式按两选标签校验(未展示的 auto / manual 标签 = 答的不是这张卡 ⇒ dismissed)。
             const decided = planReviewDecisionFromAnswer(answer, LEGACY_TWO_CHOICE_LABELS);
             if (decided === 'dismissed') {
-                // 三态(REF-CC-026):dismiss/读不出不驱动 decidePlanReview;呈现台账不清 ——
-                // 这张卡再被重开就是真「reopened」。
                 return { ok: true };
             }
-            // A-024.4(#244 F1 起走分代):决断递交即消费呈现史(与 arm 臂 responder 同点;overlay 的
-            // answerAndRelease 对同一张卡也会经 notePlanReviewAnsweredIfDecisive 报一次,按完整
-            // questionId 去重,不双推)。
             notePlanReviewAnsweredFor(sessionKey, questionId);
             try {
                 await deliver(taskId, decided);
             }
             catch (e) {
-                // 投递编排是注入方的职责面(缺省臂自带 outcome 管道不会走到这);这里只留痕,
-                // 绝不把宿主投递臂的 throw 冒进 overlay 的 respond 链。
                 hostLog('error', `planReviewWire: reopen decision delivery threw for task ${taskId}: ${String(e)}`);
             }
             return { ok: true };
         });
         activeReopenResponders.set(activeKey, { questionId, unregister });
         if (receiptMs !== undefined) {
-            // 回执模式(#250 件1):零登记(登记时点 = 宿主 overlay 真入队点)、订阅先于 publish、
-            // 回执键 = 原始帧 id(尝试级回执 —— 同 gate 并发重开不同键互唤);窗尽如实 false,
-            // responder 故意保留(迟到卡必须仍可答,决断腿照走)。
             const receipt = waitForGateArmedFor(sessionKey, [questionId], receiptMs);
             publishQuestionFrameFor(sessionKey, {
                 type: 'question',
@@ -765,7 +463,6 @@ export function reopenPlanReviewCard(taskId, opts) {
         return { reopened: true, firstSight };
     }
     catch {
-        // 重开失败绝不炸 turn —— 调用方会如实说「没能重开」(回执模式回同形的 resolved promise)。
         return receiptMs === undefined ? { reopened: false } : Promise.resolve({ reopened: false });
     }
 }