架构与设计取舍

01为什么指标必须是纯函数

体检结论要被拿去开周会——错了、变了、说不清，第三次就没人信了。纯函数给三条硬保障：

• 可复现：同一份台账，今天跑和下周跑结果逐字段相同，报告可以贴进周报存档。
• 可单测：五个指标的判据正确性与 IO 完全解耦。
• 可断言：不读时钟、不读网络、不读环境变量——也就没有「环境问题」可甩锅。

02为什么是 stdio MCP

体检引擎（core/js/）与宿主之间只隔一层 stdio 协议壳（hosts/mcp/project_server.mjs）：壳不含判断逻辑，引擎不做 IO。要接新宿主，写一个壳就行。

03诊断与处方为什么分开、又合在一个仓

• 分开：诊断（check.analyze）只对「此刻数据能支撑的判断」负责；处方（plan.suggest）把每条风险映射成一个动作。混在一起，用户分不清哪句是事实、哪句是建议。
• 同仓：只给诊断，用户拿到一张打分的表还得自己琢磨；只给处方，建议没有诊断兜底就是拍脑袋。合成一件才成立。
• 共同的底线：每条结论都必须挂证据行，无证据不出结论、无证据不出建议——这一条同时写进了两个工具的行为里。

04为什么计划生成是规则式不是模型式

排期建议的判据（完成殿后、阻塞前置、临期优先）是团队共识，规则式就能表达；引入模型换来的是不可复现和不可解释。模型的位置在「读会议纪要抽数据」那类上游活，不在体检判定这一步。

05findings.json：先定协议，再接上游

体检结果是标准的 findings.json，可直接进 CI 或周报。协议先定，意味着上游数据源（项目管理工具导出、人工台账、未来的导入器）谁来都行——RecoScan 只认协议，不绑数据源。

06明确不做的三件事

• 不做根因推断、不做风险预测：它给「哪里不通」和「先动哪个」，不是「为什么会这样」。
• 不做自动抽数：从会议和知识库自动抽数据属于上游，它只认台账。
• 不做跨项目组合视角：一次看一个项目，边界刻意收窄。