Jyotisha/docs/tasks/PROGRESS-consult-prep-parallel-20261013.md

PROGRESS · 发问准备并行（2026-10-14）

• 分支：codex/consult-prep-parallel-20261013
• 基线：origin/staging 66cd60081f37a57680274633fcb3fb942d01bb2f（任务书写的 77057a819 的后代；计划评论里的 2994588ad 更早，不因此停工）
• 个人长报告写作开关仍是关闭，本轮没有改报告章节
• 编号：本分支上的 docs/BUG_HISTORY.md 最大号是 BUG-1322。BUG-1323～1336 被其它未合并任务书占用。本单用 BUG-1337～1339

开关

三个都保持代码里的默认，没有单独提交去打开：

开关	默认	原因
CONSULT_PREP_PARALLEL	关	没有本机 Postgres 中位数，不满足首帧快两成
MODEL_VERSION_CACHE_TTL_MS	0	没有量到「准备模型」快一半
CONSULT_DOMAIN_CONCURRENCY	1	没有带星盘网络库的镜像重测；起草试算预计达不到快两成五

因此没有写 CHANGELOG.md，也没有改 frontend/DESIGN.md。

做了什么

• T1：开流前的登录、注销检查、请求体、会话、模型收进 loadConsultTurnHead。并行时注销检查和后面三条同时开始，失败仍按旧的先后返回。423 仍在任何扣点之前。
• T2：并行打开时，审核在开流前启动、在扣点前等待。拦住时不扣点，并且比资料错误优先。关掉时仍是开流前等待审核。
• T3：按模型和版本缓存成功的解析，最长 15 秒；失败和空结果不缓存；管理端清目录缓存时一并清掉。地址检查函数本身没改。已发布版本的供应商代码、类型和地址不可变，但启用开关和密钥仍可变，所以不能超过目录缓存的 15 秒。
• T4：问题保存成功后立刻读标题，和分类同时进行，用到标题时再等。分类仍在扣点和保存之后。
• T5：领域并发开关。为 1 时仍是原来的逐个循环，含时间预算。为 2 时一起算，结果按计划顺序组装，不再逐个套时间预算，领域个数上限不变。
• T6：准备阶段记一条 consultation-prep-v1，只有阶段名、毫秒和状态，没有问题原文。
• T7：见 docs/testing/consult-prep-parallel-ab-20261013.md。假时钟并行 160、串行 210。这不是开启依据。
• 测试注入：模型目录增加 setModelCatalogIoForTests，只给测试替换查库、解密和地址检查。生产路径仍调用原来的函数。

改过的既有断言

文件	原值	新值	原因
content-moderation.test.ts	源码含 await moderate(visibleQuestion, "input" 且早于 reserve_consultation_usage	await settleInputModeration() 早于扣点；准备服务里 beforeReserve 早于 input.reserve()；拦住时扣点次数是 0	审核挪到流内、扣点前。关掉开关时开流前的等待还在
model-catalog.test.ts	return await readVersion(modelId, configVersion)	const model = await readVersion(...)，只有非空才写入短缓存	绑版本的解析可以缓存，失败和空结果不写
model-catalog.test.ts	咨询路由里 if (!sessionModel) 后面是 503	准备函数里 if (!sessionModel) 返回 modelUnavailable()，状态 503	模型不可用仍是开流前的 503，文案随准备步骤搬走
consult-first-frame-and-pacing-20260928.test.tsx	401、请求体、会话不存在、会话类型、模型已变这些字面量在路由的 runTurn 之前	字面量在 turn-prep.ts；路由在 runTurn 之前调用 loadConsultTurnHead 并返回失败	开流前的判断收进同一个函数，状态码仍在开流前
rectification-session-composer-guard.test.ts	咨询路由里会话缺失返回 404，类型不对返回 session_not_consultation	同样两句在 turn-prep.ts	会话判断搬走，文案和状态码没变

consultation-agentic-runtime.test.ts 的领域循环帮助函数现在也接受异步的假计算，以便断言「后完成的领域仍排在计划后面」。原有断言没有改松。

并发为 2 时的时间预算

领域数仍先被原来的上限截断（现在是 2）。开关为 2 时，这两个领域一起开始，不再逐个问「剩下的时间还够不够下一个」。开关为 1 时，原来的逐个判断还在。

自测

test:db 未跑：本轮没有改查询语句，任务书也不要求。前端全量和 Python 快速门留给验收。npm run lint 0 error，原有 warning 没动。

检查	命令	结果
类型	node frontend/node_modules/typescript/bin/tsc --noEmit -p frontend	0 错
规范	npm run lint --prefix frontend	0 error，125 条原有 warning
准备与审核	tsx --test 下列文件：consult-turn-prep-20261013、consult-prep-gate-20261013、content-moderation、model-catalog、consult-first-frame-and-pacing-20260928、rectification-session-composer-guard	准备函数 3 通过；门禁文件 5 通过；其余在同一次 41 例里通过（当时缓存测试还在改，后来单文件 5 通过、失败 0、取消 0）
计费、注销、标题、寒暄、领域	同上命令：application-billing-contract、account-deletion、session-title-persist-contract、consultation-smalltalk、consultation-agentic-runtime	136 通过，失败 0，取消 0
假时钟	consult-prep-parallel-ab.mts	并行 160，串行 210，同时步数 2 对 1
领域镜像	consult-domain-concurrency-ab.py	退出 0，写明没有跑镜像

第 1 次打回

合并最新 origin/staging。业务代码没改，三个开关默认值没改。

文件	原值	新值	原因
chat-session-authority.test.ts	在 route.ts 里找 if (!chatSession) 后的 404	在 turn-prep.ts 里锁 sessionMissing() 的 404，和分开的 notConsultation() 409	判定搬走了。仍不许并成一个判断
consultation-workflow-contract.test.ts	beforeReserve: ({ consultationMode }) => createConsultationPlan({，以及 reserve: () => reserveConsultationModel(	beforeReserve 的 async 函数体里调用 createConsultationPlan({，并且早于 reserve；reserve 的 async 函数体里调用 reserveConsultationModel(	改成了 async。没有放宽成「文件里出现过函数名」
consult-prep-parallel-ab.mts	frontend/scripts/research/，从 frontend/tests 导入	frontend/tests/consult-prep-parallel-ab.mts	镜像会复制 scripts、不复制 tests。另一个新增的领域脚本是 Python，不导入测试目录

这次自测：上述合同测试加出生时间模式、镜像导入检查，40 通过，失败 0，取消 0。假时钟脚本挪走后仍是并行 160、串行 210。tsc --noEmit 0 错。npm run lint 0 error，125 条原有 warning。全量 npm test 留给验收。git diff a0e223e2 到本修复会带上合并进来的测试环境前端文件；相对那次合并的 origin/staging，frontend/src 没有新增改动。