当安全发现已完成复现与可行性评估后…

对已确认的安全发现，依据复现证据、生产可行性与威胁模型，计算 impact/likelihood/context multiplier 得出最终风险分与优先级，并原地更新 finding JSON。

适用场景

解决思路

1. 先解析代码根目录（Locator Resolution）：本阶段为 FINDINGS-ONLY，跳过步骤 2-6，但仍从 state 读取 active_snapshot 用于溯源与标注；绝不因代码根未设置而停止。
2. 确定 CODE_ROOT 的优先级：a) 本次调用传入 --target_root 则以其为准（权威，覆盖 SNAPSHOT_ROOT 与 state 回退）；b) 否则若传入 --snapshot_root（或 SNAPSHOT_ROOT）则使用它；c) 否则读取 state_root/workspace/.mantis_state.json 的 active_snapshot.root/.snapshot_id/.snapshot_pinned；d) 否则 CODE_ROOT = 当前目录，snapshot_pinned = false（MODE-OFF），不要停止。
3. 哨兵检查（仅当 snapshot_pinned 为 true 且未走 1a 路径）：验证 CODE_ROOT/.mantis_snapshot_id 存在且等于 SNAPSHOT_ID，否则 STOP "snapshot sentinel mismatch"；--target_root 树为哨兵豁免。
4. 路径字段处理：SNAPSHOT-RELATIVE（在 CODE_ROOT 下读取）包括 code_paths 条目与 plan target_files 中的文件路径，仅剥离末尾的 :<digits>；含 "://" 的条目是 URL/端点而非文件读取；非 <existing-path>:<integer> 形式的条目是非源码 LOCATOR（符号/偏移/端点），只检查其存在性并跳过所有行范围与行存在性逻辑。STATE-RELATIVE（在 state_root/workspace 下读写，绝不加 CODE_ROOT 前缀）包括 kb_references、repro_file_path、reattack_file_path、helper 脚本、报告文件及所有 state/findings JSON。
5. 当 snapshot_pinned 为 true 时绝不写入 CODE_ROOT；任何编译、生成或写入产物的命令必须在私有影子副本（从 CODE_ROOT 用 mktemp -d 创建）中运行，绝不使用 cwd=CODE_ROOT；只读检查可以 cd 进入 CODE_ROOT。
6. VCS 元数据例外：历史日志提取与任何 VCS diff/blame 命令在仍含 .git/.hg/.repo 的实时仓库根运行，而非 CODE_ROOT（快照副本剥离了 VCS 元数据）；不要仅因 CODE_ROOT 缺少 .git/.hg/.repo 而停止。
7. 每条 shell 命令使用绝对路径并在该次调用中自行设置工作目录，不要假设工作目录在调用之间保持。
8. 当前 pass 防御性检查：若 active_snapshot 存在且 active_snapshot.pass != state.pass_number，则视为本 pass 快照过期——STOP "stale active_snapshot: pass mismatch" 或按 HALT 降级（snapshot_pinned 实际为 false：无权威判定、Block B NOT_MATCHED、reproduce not_attempted）。
9. 快照溯源与 STALE-EVIDENCE 守卫（机械步骤，评分前执行）：P0 从 state_root/workspace/.mantis_state.json 读取 active_snapshot（{snapshot_id, snapshot_pinned, root}），缺失时绝不停止。
10. P1 确定 MODE（整个运行单一决策，3 态模型）：active_snapshot 缺失（未请求 --sync）→ MODE-OFF，完全按今天方式评分，不计算 PROVENANCE、不输出 STALE_EVIDENCE、不输出 HALT/PINNED 横幅；active_snapshot 存在且 snapshot_pinned 不严格为 true → MODE=HALT，SNAPSHOT_ID = active_snapshot.snapshot_id（live: id），按 P2 计算 PROVENANCE 并保守触发 STALE-EVIDENCE 守卫，本 pass 禁止权威判定（VERIFIED_SECURE、failed_to_reproduce、DUPLICATE、FALSE_POSITIVE、NON_VIABLE）；snapshot_pinned == true → MODE=PINNED，SNAPSHOT_ID = active_snapshot.snapshot_id，执行完整溯源与守卫。
11. P2 在 PINNED 或 HALT 模式下按 Block B 比较规则计算每个 finding 的 PROVENANCE：F.discovery_commit 缺失、为空或字面量 "MIXED" → NOT_MATCHED；F.discovery_commit != SNAPSHOT_ID（精确字符串比较，不模糊）→ NOT_MATCHED；相等 → MATCHED。
12. P3 当 MODE 为 PINNED 或 HALT 且满足以下任一条件时，该 finding 的启发式为 STALE：PROVENANCE(F) == NOT_MATCHED，或该 finding 的 code_paths 目标文件在 CODE_ROOT 下不存在（按 Block A 步骤 1 与 3 解析 CODE_ROOT，剥离末尾 :<digits>，只读固定根，绝不读实时树；完全无法解析 CODE_ROOT 时视为文件缺失 → STALE）。
13. P4 当启发式对 F 为 STALE 时：不应用该启发式，保留保守（调整前）分数，并确保字面 token STALE_EVIDENCE 是 sanity_triage_applied 的第一个 token（在任何 UNKNOWN 警告与已触发规则列表之前添加一次）。四个受守卫启发式及其 STALE 处理：dead-code 0.2 乘数不应用，使用原本会用的乘数；repro_failure 不强制 LOW，设 calibration_checklist.repro_failure.outcome = "UNKNOWN" 且 reason 以 "STALE_EVIDENCE: " 开头；vague_code_paths 不强制 LOW，设 outcome = "UNKNOWN" 且 reason 以 "STALE_EVIDENCE: " 开头；static_confirmation trace-lift 不应用，保持静态 HIGH 上限（likelihood_score <= 3、0.8 Hazard 乘数、非 CRITICAL），设 outcome = "APPLIES" 且 reason 以 "STALE_EVIDENCE: trace-lift suppressed; trace/crash-log may predate the active snapshot; " 开头。
14. P5 非源码 finding：若 code_paths 条目是非源码 LOCATOR（含 "://"，或非 <path>:<integer> 形式），跳过所有仅源码启发式（dead-code、文件路径/imports/调用层级暴露推断、vague_code_paths、静态 trace 重检），仅依据 finding 声明的元数据（attacker_position、privileges_required、production_viability、repro_status、威胁模型）评分；非源码跳过不标记 STALE_EVIDENCE；非源码 finding 的 inferred_exposure 默认 "INTERNAL"（0.8），除非 finding/威胁模型另有声明。
15. 加载完整流水线状态：读取 workspace/findings/ 下所有 JSON 文件，获取每个 finding 的完整历程（id、复现状态、生产可行性）。
16. 缺失字段回退：production_viability 缺失时视为 "CONDITIONAL_VIABLE"；repro_status 缺失时视为 "not_attempted"。
17. 仅在 PINNED 或 HALT 模式下，按 P2 为每个 finding 计算 PROVENANCE（MATCHED/NOT_MATCHED）并记入草稿，用于门控第 2、3 节的 STALE-EVIDENCE 处理；MODE-OFF 时跳过。
18. 读取 workspace/kb/THREAT_MODEL.md（若存在），评估组件暴露面、信任边界、资产关键性及自定义 Calibration Overrides（如特定威胁位置或应提升/定制的上限）。
19. 批处理：finding 较多时拆成小批（每次几个），若可调用子代理则并行委派每批再汇总；每批/子代理只检查固定快照，传入 --snapshot_root=<active_snapshot.root>、--snapshot_id=<active_snapshot.snapshot_id>、--state_root=<workspace parent>，使所有子代理经 Block A 解析出同一 CODE_ROOT；任何代码检查必须通过该 CODE_ROOT（固定副本）读取，绝不读实时树，并遵守 STALE-EVIDENCE 守卫；仅 findings 字段（分数、优先级、history 戳）无论何种模式都从 finding JSON 计算。
20. 计算风险分（1-10）：对每个唯一 finding 文件按矩阵公式计算，Hazard = Impact + Likelihood。
21. Impact（1-5）：按 CIA 三元组并严格考虑爆炸半径。5：完整性/机密性完全系统性丧失（全量数据泄露、根加密/HSM 主密钥泄露）或系统沦陷（如非特权攻击者实现清晰 RCE，且其原本不处于可执行代码的位置）；不得用于已具备执行权限的攻击者。4：一个或多个领域重大损失，包括系统性可用性丧失（主要服务全面中断）或重大数据暴露。3：中等损失（部分数据暴露、临时或部分系统中断）。2：轻微损失（轻微信息泄露、局部中断）；爆炸半径仅影响单个用户自身数据的漏洞不得超过 2；例外：若操作缺乏不可否认性（用户可合理否认以实施欺诈或嫁祸），或触发影响其他用户/系统稳定性的副作用，则不应降级。1：对 CIA 影响可忽略，基本为外观问题；"代码脆弱"、"缺乏纵深防御"或纯理论卫生类 finding 的 Impact 必须为 1，确保至多 LOW。
22. 安全控制绕过升级：若漏洞直接绕过核心安全控制（认证、授权、密码签名验证）或破坏库的主要安全目的（如本应保护密钥集的库允许攻击者控制），即使即时技术影响看似局部，Impact 至少提升到 4（若导致系统性沦陷则 5）。
23. 权限与横向移动说明：若 finding 需要 HIGH 权限（管理员权限、admin 到 super-admin 提权）或仅允许从已沦陷状态在内网组件间横向移动/跳板，其单项 Impact 上限为 2，除非利用可逃逸容器边界（到宿主节点）或跨租户提权；若需要 LOW 权限（标准已认证用户），单项 Impact 上限为 3，除非导致其他租户/用户的系统性沦陷，或直接绕过核心安全控制/库目的（此时可更高）；这些上限适用于单项 finding；若被 chainer 成功串联为利用链（Super Finding），链本身按链入口点（初始步骤）所需权限级别评估。
24. Likelihood（1-5）：基于已证实的可利用性而非理论难度。5：已在野利用，或代理成功生成可用的武器化利用（不只是单元测试）。4：存在公开 PoC，或代理生成高度可信但部分武器化的利用。3：无可用利用，但攻击向量易于自动化。2：理论且高度复杂（需本地访问、严格时序）。1：纯理论风险，无已知利用路径。
25. 实践可达性修正：确定基础 likelihood 后，若利用路径依赖罕见或非默认使用模式，将 likelihood_score 降低 1 或 2（但不低于 1.0）；适用情形：特定污点参数仅在罕见 API 调用、不常见配置字段或野外很少处理的数据格式中由攻击者输入填充；漏洞需要实践中很少启用的非标准或仅管理员配置。
26. Context Multiplier（0.1-1.0）：若 status 为 FALSE_POSITIVE 或 NEEDS_RESEARCH，或 production_viability 为 NON_VIABLE，则完全丢弃该 finding，不评分也不写入校准数据。
27. 若 production_viability 为 VIABLE、CONDITIONAL_VIABLE 或 SAMPLE_OR_TEST，按网络/信任暴露确定乘数：位于暴露接口/信任边界（可直接被不可信输入访问）为 1.0；位于接受半可信解析数据的内部组件为 0.8；深嵌于特权/受信区为 0.5。
28. 威胁模型缺失/不完整时的推断：若 workspace/kb/THREAT_MODEL.md 不存在或未提及该组件，分析文件路径、imports 与调用层级推断暴露面（如公共 API vs 内部 helper），只读固定 CODE_ROOT，绝不读实时树；非源码 finding 跳过此文件路径/imports/调用分析，inferred_exposure 默认 "INTERNAL"（0.8），除非 finding 或威胁模型另有声明；当 MODE 为 PINNED 或 HALT 且 finding 为 NOT_MATCHED 或其 code_paths 文件在 CODE_ROOT 下缺失时，不得基于实时重检把暴露乘数降到声明/默认值以下（保留保守的较高乘数）；默认 Exposure Multiplier 为 0.8（Internal）、inferred_exposure 为 "INTERNAL"，除非有明确证据表明直接外部暴露（EXPOSED）或深层嵌套隔离（PRIVILEGED）；本地 SUID/LPE 二进制默认 "INTERNAL" 暴露；若 finding 描述、history 或 critic 推理表明组件"很少暴露"、"仅内部"或"不太可能被攻击者触及"，将 Exposure Multiplier 降至 0.5 或更低。
29. 映射暴露与攻击者位置元数据：按乘数解析 inferred_exposure——1.0（暴露接口）→ "EXPOSED"，0.8（内部组件）→ "INTERNAL"，0.5（特权/受信区）→ "PRIVILEGED"。
30. 评估攻击者位置（finding 中声明）：读取 finding JSON 的 attacker_position；按屏障而非传输协议判定——attacker_position 必须表示第一个不可信主体（最终人类攻击者或外部威胁行为者）到达该接口必须跨越的最外层边界，不要以传输协议（HTTP、gRPC、IPC）或直接协议对端为准。
31. 回溯到不可信行为者：若与接口交互的直接对端是设计上受信的组件（内部代理、网关、消息队列、主控制器），必须回溯数据流找到不可信行为者首次进入系统的最外层边界。
32. 若接口绑定 localhost 或使用本地 IPC（unix socket、管道、共享内存），位置为 "LOCAL"，即使底层使用 HTTP/TCP。
33. 若接口仅在私有网络（VPC、企业网、家庭 LAN、本地网络、内部集群控制面）内可达，位置为 "INTERNAL_NETWORK"（若限于 pod 到 pod 则为 "IN_CLUSTER"），即使它是 Web 服务。
34. 仅当接口可从公网直接可达时位置才为 "EXTERNAL"。
35. 若接口需要物理接触、硬件交互（JTAG、调试探针、芯片开盖）或本地无线接近（NFC、蓝牙），位置必须为 "PHYSICAL_TEMPORARY" 或 "PHYSICAL_LONG_TERM"，无论使用何种协议。
36. 规范化自由文本：若值存在但不精确匹配有效枚举（如遗留措辞），必须按以下映射规范化为最接近的有效枚举：匹配 "authenticated <role>"、"customer with"、"tenant <role>"、公共产品上的 "Fitbit user" → "EXTERNAL"（并设 privileges_required: "LOW"）；匹配 "local user"、"local shell"、"local access" → "LOCAL"；匹配 "peer <role> in same job/cluster/pod"、"co-tenant"、"in-cluster (Kubernetes/container-orchestrator) workload"、"NCCL peer rank" → "IN_CLUSTER"；匹配 "malicious dependency"、"upstream package"、"build-time"、"CI pipeline" → "SUPPLY_CHAIN"；匹配 "host hypervisor"、"host OS"、"hypervisor access" → "HOST_SYSTEM"；匹配 "physical access"、"fault injection" → 按屏障为 "PHYSICAL_LONG_TERM" 或 "PHYSICAL_TEMPORARY"。
37. 若完全缺失，按以下回退推断（并记录警告建议尽早声明）："EXTERNAL" 若组件为 "EXPOSED" 或为公共门户上的认证绕过；"LOCAL" 若为本地提权（LPE）或 SUID 利用；"IN_CLUSTER" 若从 pod 攻击集群内基础设施（CSI/CNI）；"HOST_SYSTEM" 若攻击者是 hypervisor、宿主 OS 或模拟/物理设备攻击其托管的软件（guest 驱动、enclave 运行时、固件目标）——该枚举严格用于外到内方向，反向（guest 到 host 的 VM 逃逸、沙箱到外部、enclave 到 host、受控进程到容器）必须归类为 "LOCAL"（Kubernetes pod 到节点为 "IN_CLUSTER"；KVM/hypervisor guest 攻击其 host 为 "LOCAL"），绝不用 "HOST_SYSTEM"；"PHYSICAL_LONG_TERM"/"PHYSICAL_TEMPORARY" 若 bug 描述、标题或代码路径表明硬件故障注入、侧信道、evil maid 或 USB 物理访问；"SUPPLY_CHAIN" 用于构建期或依赖修改前提；"INTERNAL_NETWORK" 作为其他内部组件的默认回退。
38. 对齐暴露与位置：若 attacker_position 为 "LOCAL" 或 "IN_CLUSTER"，必须将 inferred_exposure 解析为 "INTERNAL"（0.8 乘数），即使漏洞代码路径位于威胁模型中映射为 "EXPOSED" 的目录，除非利用明确逃逸容器边界到宿主节点；若为 "INTERNAL_NETWORK"，必须将 inferred_exposure 解析为至多 "INTERNAL"（0.8 或更低），即使组件在威胁模型中映射为 "EXPOSED"，因为接口不能从公网直接可达；若为 "EXTERNAL"，必须将 inferred_exposure 解析为 "EXPOSED"（1.0 乘数），即使组件在威胁模型中映射为 "INTERNAL" 或 "PRIVILEGED"（反映不可信外部输入可到达该组件）。
39. 资产关键性与可达性：若威胁模型表明组件处理高价值数据（PII、核心密钥），保持高乘数；若影响低价值目标（内部分析、沙箱测试数据），降低乘数（如 0.5）。
40. 可用性专用上下文：若 finding 仅涉及可用性（DoS），检查威胁模型中组件的 availability_tier（缺失则默认 STANDARD）：LOW_CRITICALITY 将乘数降至 0.5；STANDARD 降至 0.8；CRITICAL 保持 1.0。
41. 若静态/动态分析证明漏洞代码实际为"死代码"（运行时执行路径中从不调用），大幅将乘数降至 0.2；STALE-EVIDENCE 守卫：若 finding 为 STALE（MODE 为 PINNED 或 HALT 且 finding 与活动快照 NOT_MATCHED、code_paths 文件在固定 CODE_ROOT 下缺失），不应用该 0.2 降幅——漂移代码可能虚假地看起来"未被调用"——保留较高乘数并将 STALE_EVIDENCE 设为 sanity_triage_applied 的第一个 token；任何死代码分析必须检查固定 CODE_ROOT，绝不读实时树；非源码 finding 完全跳过该启发式。
42. 用户交互：若 user_interaction 为 REQUIRED（CSRF、点击劫持、诱使用户打开恶意文件），对 Context Multiplier 应用 0.7 乘数（如内部暴露 0.8 且需用户交互，则合并乘数为 0.8 * 0.7 = 0.56），确保这些 finding 被压在 CRITICAL 阈值以下。
43. 若 production_viability 为 SAMPLE_OR_TEST：对 Context Multiplier 应用 0.4 缩放因子（即当前乘数乘以 0.4），使示例代码中的严重 bug 通常落入 MEDIUM 而非 HIGH/CRITICAL；该缩放因子必须与其他修正累积应用，不要直接把 Context Multiplier 覆盖为 0.4，否则当组件暴露或死代码状态已算出低于 0.4（如 0.2）时会错误地提高它；在 executive_summary 中明确说明这不是生产 bug，建议必须聚焦修复示例/测试，避免开发者把不安全模式复制到生产代码。
44. 若 production_viability 为 CONDITIONAL_VIABLE：对 Context Multiplier 应用 0.7 缩放因子（即当前乘数乘以 0.7），反映其需要特定非默认配置、编译器标志或启用的断言才可利用；该缩放因子必须与其他修正（如用户交互）累积应用，不要直接把 Context Multiplier 覆盖为 0.7，否则当组件暴露已很深/隔离（0.5）时会错误地提高它；在 executive_summary 中记录可行性所需的具体条件。
45. 最终分数（Hazard）= (Impact + Likelihood) * Multiplier，上限 10.0。
46. 关于 Outrage：在推理中评论更广的等式 Risk = Hazard + Outrage，其中 outrage risk（声誉损害、用户情绪反弹）需考虑，但不要把 outrage 因子计入最终数值分数。
47. 关键理智分诊（降级与封顶）：在确定最终优先级前，对 finding 质量、上下文与累积证据做二级检查。
48. 核心原则——边际能力：finding 的最终严重性与优先级严格受攻击者相对其前提位置所获得的边际能力约束；若利用未赋予攻击者显著超出其起始位置固有（或已通过合法手段拥有）的新控制、访问或能力，必须封顶或降级。
49. 完整详细的 27 条校准理智规则定义存于参考目录 references/calibration_rules.md，必须对每个 finding 逐条评估这 27 条规则。
50. 检查 THREAT_MODEL.md 是否定义 Calibration Overrides（如 LIFT_CAP: PHYSICAL_LONG_TERM）；若存在针对该 finding 位置或组件的覆盖，其优先并解除相应上限；否则参考目录中的上限与降级（及边际能力原则的一般应用）覆盖第 2 节算出的任何升级（包括安全控制绕过升级）；也应将一般原则应用于封顶或降级其他低边际能力的 finding；重要：HIGH 或 MEDIUM 上限只限制最大允许分数/优先级，绝不能提升更低的分数/优先级（如 5.0 分的 finding 天然为 MEDIUM，即使受 HIGH 上限约束也必须保持 MEDIUM）。
51. 优先级与 UNKNOWN 规则：STALE-EVIDENCE 优先——当 MODE 为 PINNED 或 HALT 且 finding 为 STALE（与活动快照 NOT_MATCHED，或其 code_paths 文件在固定 CODE_ROOT 下缺失）时，以下规则不得用于基于实时重检降低或抬高分数：repro_failure（不强制 LOW）、vague_code_paths（不强制 LOW）、static_confirmation 的 trace-lift 例外（不把过期 trace/sanitizer/crash-log 当作实时复现——保持静态 HIGH 上限）；也不应用第 2 节的 dead-code 0.2 乘数；保留保守分数并将字面 token STALE_EVIDENCE 前置为 sanity_triage_applied 的第一个 token（在任何 Incomplete Calibration (UNKNOWN: …) 警告与已触发规则列表之前）；按 P4 在 calibration_checklist 中记录受守卫规则（repro_failure/vague_code_paths → UNKNOWN 且 reason 带 STALE_EVIDENCE: 前缀；static_confirmation → APPLIES 且 reason 带 STALE_EVIDENCE: 前缀说明 trace-lift 被抑制）；MODE-OFF 时该条不生效（按今天方式评分）。
52. 评估所有规则；若多个上限适用，最严格者胜（Force-LOW > cap-MEDIUM > cap-HIGH）。
53. UNKNOWN 结果策略：若某规则评估为 UNKNOWN，不应用该上限或降级（评分保守，保持较高的计算分数/优先级）；但需在 sanity_triage_applied 字符串前添加警告标记整体校准不完整/暂定："Incomplete Calibration (UNKNOWN: <rule_name>)"（多个 UNKNOWN 时用分号分隔列表），提示需人工复核解决规则状态。
54. 将每个成功触发/应用的规则以分号分隔列表记录到 sanity_triage_applied，最严格者在前（如 "Local Attack Vector; Internal/Nested"），若有 UNKNOWN 警告则追加在其后，使有效上限完全可审计。
55. 确定优先级：CRITICAL（8.0-10.0）需立即行动，极高危险（高影响与高可能性）；除非代表非特权攻击者（privileges_required 为 NONE）且其原本不处于可沦陷系统的有效位置、且 user_interaction 为 NONE（零点击）的清晰 RCE（或等价完全损失），否则不得使用；该规则绝对：即使某 finding（如 CSI 宿主逃逸）的第 3 节上限被解除，若入口需要 HIGH 权限，也不得评为 CRITICAL，必须封顶为 HIGH（7.9）；仅可用性 finding（DoS）不得评为 CRITICAL，除非威胁模型明确记录 availability_tier 为 CRITICAL 且无自动恢复机制（自动重启、负载均衡故障转移）缓解影响。
56. HIGH（6.0-7.9）：高优先级，显著危险，需尽快解决。
57. MEDIUM（3.0-5.9）：标准优先级，中等危险，可排期。
58. LOW（0.1-2.9）：低优先级，最小危险；任何"代码脆弱"、纯卫生/纵深防御、或仅影响单个用户自身数据的 finding 必须封顶为 LOW 优先级，无论计算分数如何（除非缺乏不可否认性或更广副作用的例外适用）。
59. Token 优化文件更新：为最小化 LLM 输出 token，不要重新输出或手写整个 JSON 对象；在首次更新 finding 时编写可复用 helper 脚本（如 workspace/helpers/append_calibrate.py），后续 finding 不重新生成脚本，仅以新参数执行已有 helper 将所需字段追加到 workspace/findings/<id>.json。
60. Helper 版本标记（强制）：append_calibrate.py 的第一行必须是精确注释 # MANTIS_HELPER_VERSION = 2；复用已有 helper 前读取其第一行：若文件缺失，或第一行不是精确的 # MANTIS_HELPER_VERSION = 2（标记缺失或整数不同），必须从头重新生成 helper（旧 helper 会静默丢弃新的 snapshot history 字段与 STALE_EVIDENCE 处理）；重新生成的 helper 必须能把 snapshot 键写入追加的 history 条目，并能把 STALE_EVIDENCE 前置到 sanity_triage_applied；helper 为 STATE-RELATIVE（workspace/helpers/…，Block A 步骤 3），绝不写入 CODE_ROOT 下。
61. 除现有核心 finding 数据外，显式追加以下字段以展示矩阵分解："impact_score"（1-5）、"likelihood_score"（1-5）、"availability_tier"（CRITICAL、STANDARD、LOW_CRITICALITY 或 null）、"inferred_exposure"（EXPOSED、INTERNAL 或 PRIVILEGED）、"attacker_position"（从输入保留，缺失时按回退推断填充）、"mantis_risk_score"（最终 Hazard 分数）、"priority"（CRITICAL、HIGH、MEDIUM、LOW）。
62. 追加 "sanity_triage_applied"（分号分隔列表或 null），顺序：若 finding 为 STALE 则 STALE_EVIDENCE 在前（P4）；然后是任何 Incomplete Calibration (UNKNOWN: <rule>) 警告；然后是第 3 节触发的规则，最严格者在前；示例："STALE_EVIDENCE; Incomplete Calibration (UNKNOWN: physical_long_term); Local Attack Vector"。
63. 追加 "calibration_checklist" 对象，包含全部 27 条理智上限的评估，每个键映射到同名规则：repro_failure、unreachable_inputs、third_party_reachability、minor_config_hygiene、non_security_critical、vague_code_paths、unreliable_triggers、prerequisite_shell、physical_long_term、trusted_controller_zero_delta、standard_host_attacks、static_confirmation、strict_xss、internal_nested、probabilistic_llm、supply_chain_prerequisites、non_default_config、confidential_computing_host、trusted_controller_critical_bypass、local_attack_vector、self_contained_blast、rarely_exposed、equivalent_primitives、documented_insecure_config、physical_temporary、high_privilege_external、trusted_controller_standard_bypass；每条规则 outcome 取值："APPLIES"（规则触发，封顶或降级分数/优先级，必须提供详细 reason）、"DOES_NOT_APPLY"（不适用，reason 可选可省略以省 token）、"UNKNOWN"（未解决，必须提供详细 reason）；为向后兼容，schema 也允许 "fires": <bool>（仅当 fires 为 true 时 reason 必填），但优先使用新的 "outcome" 格式。
64. 追加 "outrage_commentary"（关于 outrage 因子的推理）与 "executive_summary"。
65. 向 "history" 数组追加条目：{"stage": "calibrate", "action": "calibrated", "details": "Calculated risk score as [score] and priority as [priority].[ STALE_EVIDENCE: scored without trusting live-code re-inspection.]", "pass_number": <current_pass_number>, "snapshot": "<active_snapshot.snapshot_id, or omit in MODE-OFF>", "timestamp": "<current_iso8601_timestamp>"}。
66. 将更新保存到各个 finding 文件，完成后通知用户。

适用边界 · 注意事项

• 不要用于发现新漏洞（该阶段只对已有 finding 评分，不进行漏洞挖掘）。
• 不要用于编写补丁（该阶段不产出修复代码）。
• 不要对 status 为 FALSE_POSITIVE 或 NEEDS_RESEARCH、或 production_viability 为 NON_VIABLE 的 finding 评分或写入校准数据（应完全丢弃）。