Jyotisha/PROGRESS-rectification-decision-authority-20260831.md

生时校正决策权威重构进度（2026-08-31）

基线与交付边界

• 隔离 worktree：/Users/jesse/Downloads/Copse/astrology/.worktrees/rectification-decision-authority-20260831
• 分支：codex/rectification-decision-authority-20260831
• 基线：origin/staging @ 9aebd0474a089ed5bec1fc8e8432d0d85e93ffb6
• 2026-08-31 交付前重新执行 git fetch origin staging --prune；本地基线与远端 staging 仍一致。
• 本次只交付任务 0、A、B。任务 C、D 尚未开始；不部署，不提升 main，不声称真实 authenticated staging flow 已验证。

任务 0：不变量门控

实现前先加入五条不变量并运行，五条均红，且失败原因分别落在任务书列出的病灶：

1. TypeScript 能力超过引擎 ceiling。
2. 证据不足仍允许采用/选择。
3. 候选并列或未分离仍允许采用。
4. holdout unavailable 仍允许采用。
5. public overlay 用本地字段覆盖引擎否决。

A+B 完成后五条全部转绿：tests 5 / pass 5 / fail 0。

任务 A：停止原因分类化

• 新增三类 StopClass：keep_collecting、exhausted、user_stopped。
• insufficient_dated_events 与 insufficient_domains 只进入收集流程，不再进入 completeWithRange()。
• 真正耗尽（并列第一、用户不确定度过高）仍可结束为 review-only range。
• 用户主动停止改变的是“是否继续追问”，不是证据是否达标：允许交付区间，但不放开采用能力。
• 空候选不再返回无停止原因的 fail-open 状态，而是归入证据不足、继续收集。
• decideNextAction() 与 decideRectification() 同步演进，保留既有一致性断言。

任务 B：能力标志单一来源与引擎上限

• 新增严格四字段 EngineCapabilityCeiling：
  • acceptanceAllowed
  • selectionAllowed
  • proposeAllowed
  • confirmationAllowed
• decisionReceipt 四字段缺失、非 boolean 或字段关系非法时 fail-closed。raw dossier receipt 还会严格校验 accept_allowed / confirm_allowed alias 与 canonical 字段一致，并校验 display_allowed 不得与已允许 selection 的结果冲突。
• deliveryCapability() 成为以下四字段的唯一计算点：
  • canAdopt
  • selectionAllowed
  • proposeAllowed
  • canConfirmExactMinute
• 本地证据、coverage、holdout、separation 门与引擎 ceiling 取交集；TypeScript 只能收紧，不能放宽。
• overlayPublicDecision() 对四个门禁字段取本地结果与 receipt ceiling 的逻辑与，保留候选投影不一致时的 fail-closed。
• v9/engine-client.ts 扩展返回四个引擎能力字段。
• v9/decision-from-dossier.ts 三个调用点、core/decide-next-action.ts、v9/method-followup.ts 已逐一处理。
• method-followup.ts 的 helper 不参与生产交付，只用于问题流程，因此显式传关闭 ceiling；流程走向仍可 collect/discriminate，不会因四个交付能力全 false 而静默。
• v9/answer-choice.ts 的采用 narration 改为绑定最终能力 can_offer_range && can_adopt，避免 ready_to_adopt 丢失同回合采用载体。
• v9/turn-decision.ts 继续写入 decision.selectionAllowed；该字段现在已是 deliveryCapability() 的最终结果，无另行判门。
• frontend/src/lib/rectification-agentic/rectification-agentic/session.ts 在 frontend/src 下无生产 import，属于非活跃 legacy 路径，本轮不改。
• decideConversationalSession() 仍未接入生产路径；既有“生产工具不得调用它”的测试约束未解除。

B-1 grep 自证

以下六个分支函数内，四个能力字段均无 boolean 字面量赋值：

collect: OK
discriminate: OK
offerRangeWithoutAdopt: OK
holdoutValidation: OK
completeWithRange: OK
finish: OK

事故输入回归

输入：

• 1 条日期证据
• 1 个 domain
• 9 个候选分数：12,12,12,12,11,11,10,10,10
• trainingGateOpen=false
• methodCoverageAll=false
• snapshotCurrent=true
• 引擎 ceiling 四字段全 false

重构前任务书记录：

{
  "canAdopt": true,
  "selectionAllowed": true,
  "nextAction": "complete_with_range",
  "stopReason": "insufficient_dated_events"
}

当前输出：

{
  "canAdopt": false,
  "selectionAllowed": false,
  "proposeAllowed": false,
  "canConfirmExactMinute": false,
  "nextAction": "ask_fact_collection",
  "sessionOutcome": "collect_evidence",
  "stopReason": "insufficient_dated_events",
  "canOfferRange": false
}

既有断言修改配额

按用户批准的新口径：

• 错误行为组：6 / 6
• 修改的既有断言：10 / 12

前三条先前未列明的断言为：

1. frontend/tests/rectification-convergence-budget.test.ts:172：canAdopt true → false；病灶 3，候选未分开且预算耗尽只能交付 review-only range。
2. frontend/tests/rectification-convergence-budget.test.ts:412：label blocked → user_history_verification_required；病灶 1，空候选必须分类为证据不足而不是无原因 fail-open。
3. frontend/tests/rectification-decide-next-action.test.ts:511：sessionOutcome adopt_representative → provisional_range；病灶 4，holdout unavailable 不能进入采用态。

完整清单（按错误行为组）：

组 1：候选未分离却进入采用态（病灶 3）

1. frontend/tests/rectification-answer-choice.test.ts:608：nextAction offer_provisional_range → ready_to_adopt。原 fixture 为 16/14，回答后仍未达到 separation 门却依赖错误采用行为；fixture 已收窄修正为刚好达门的 18/14 并通过 holdout，正确采用态是 ready_to_adopt。
2. frontend/tests/rectification-convergence-budget.test.ts:172：canAdopt true → false。预算耗尽不等于候选已分开。

组 2：空候选缺少停止分类（病灶 1）

3. frontend/tests/rectification-convergence-budget.test.ts:412：label blocked → user_history_verification_required。空候选应继续收集日期证据。

组 3：无 holdout 的可信区间被当作可采用（病灶 4）

4. frontend/tests/rectification-credible-range-projection.test.ts:146：nextAction ready_to_adopt → offer_provisional_range。无 holdout 只能 review-only。

组 4：单候选但 holdout unavailable 被当作可采用（病灶 4）

5. frontend/tests/rectification-decide-next-action.test.ts:511：sessionOutcome adopt_representative → provisional_range。单候选不覆盖独立核对门。

组 5：sticky holdout 失去日期精度后仍可采用（病灶 4）

6. frontend/tests/rectification-holdout-renderable.test.ts:151：nextAction ready_to_adopt → offer_provisional_range。
7. frontend/tests/rectification-holdout-renderable.test.ts:153：sessionOutcome adopt_representative → provisional_range。
8. frontend/tests/rectification-holdout-renderable.test.ts:157：canAdopt true → false。

三条均由同一错误行为产生：sticky 只保留 holdout 身份，unknown precision 使其不可验证，必须 fail-closed。

组 6：用户停止绕过证据与 coverage 门（病灶 2）

9. frontend/tests/rectification-range-offer-deadend.test.ts:601：canAdopt true → false。用户停止只允许展示区间。
10. frontend/tests/rectification-range-offer-deadend.test.ts:608：canAdopt true → false。两条同域日期事件仍不满足独立交付采用门。

frontend/tests/rectification-holdout-renderable.test.ts 中 passed holdout 的 canAdopt === true 保持不变；只补全 receipt fixture。

未放宽的门槛

• MIN_STANDALONE_DATED_EVENTS = 3
• MIN_STANDALONE_DATED_DOMAINS = 2
• MIN_SEPARATION_LEAD = 8
• 4 事件 / 3 domain 的 exact-minute confirmation gate

本地验收

• ./node_modules/.bin/tsx --test --test-name-pattern='^invariant [1-5]:' tests/rectification-decision-authority.test.ts：5/5 通过。
• ./node_modules/.bin/tsx --test tests/rectification-answer-choice.test.ts：27/27 通过。
• ./node_modules/.bin/tsx --test tests/rectification-*.test.ts：712/712 通过，fail=0。
• ./node_modules/.bin/tsc --noEmit：exit 0。
• git diff --check：exit 0。
• .gitea/workflows/**：无改动。

尚未执行

• 任务 C：前端 selection card 的独立 receipt fail-closed。
• 任务 D：问题槽单一文案源与 Skill 10.0.14 五处同步升版。
• staging 部署与真实 authenticated flow 验证。