math-modeling-finalizer

Math Modeling Finalizer v2.1.0-rc2

本 Skill 只负责已经基本完成的项目怎样可靠收口。它不重新拥有数学事实，不建立第二套 Result/Claim Registry，也不通过固定 A—H 状态机强迫所有项目走相同流程。

默认围绕四项用户价值：

1. 参赛者尺度、行为保持的代码人味化；
2. 最终完整复审与最小 route-back；
3. 从真实 AI ledger 生成 AI 工具使用详情 DOCX；
4. 支撑材料 ZIP、DOCX/PDF 与最终交付检查。

0. 输入与事实边界

优先读取：PROJECT_CONTEXT.md、solver_handoff.json、Result Certificates、paper_handoff.json、formula_registry.json、references.bib/citation audit、ai_use_ledger.jsonl、当前论文/DOCX/PDF 和 Contest/Team Profile。 对 paper_handoff.json 不做盲目信任：进入 Freeze 前先运行 python scripts/verify_upstream_paper_handoff.py <paper_handoff.json>；任何越界路径、缺失文件或 hash 不匹配均阻断受影响的最终化 gate。

科学事实只来自 Solver Result Certificate/canonical formal output。Paper Handoff 负责当前稿件、Claim/引用/公式映射。Finalization 只验证这些链是否一致。

数学错误 → route_back.json owner=SOLVER_*；写作/引用/公式语义错误 → owner=PAPER_*；纯排版/交付问题留在 Finalization。

0.1 Freeze → Audit → Repair-safe → Revalidate → Submit

把收口视为五个可回查的决策门，而不是盲目执行的固定流水线：

1. Freeze：记录 Solver/Paper Handoff、Result Certificate、代码/文稿/PDF/ledger 的 path、SHA-256、profile 和运行配置。任何 hash 变化都使对应下游通过证据失效。
2. Audit：只检查事实链、行为链、排版链和交付链；区分 PASS、REVIEW、FAIL 和 NOT_VERIFIED。没有 exact PDF 时保留未验证状态。
3. Repair-safe：根据 owner 选择最小修改范围。Finalization 不改 Problem Contract、formal evaluator、正式结果、模型结论或 Paper 的科学 claim；发现这些问题就 route-back。
4. Revalidate：修复后只重跑受影响的最小依赖链，再跑最终交付 gate。代码 hash、Result Certificate、Evidence Registry、Paper Handoff 和 ZIP manifest 必须重新对齐。
5. Submit：只有阻塞项清零、未验证项显式披露、exact PDF 已视觉检查（若赛事要求）且人工选择/批准状态满足 Profile 时，才可标记交付通过。Finalization 不代表已替用户向平台提交。

每一门都要留下报告或结构化状态；不存在证据时写 NOT_VERIFIED，不得用“整体看起来没问题”替代 gate。

0.2 Portable Project Contract

Finalizer 继承 Solver 的 PROJECT_ROOT 相对路径契约。所有会进入 review/report/manifest/ZIP 的引用只保存项目相对路径和 hash；绝对路径只允许在运行时用于打开文件。正式输入若仍位于项目外，应先导入 inputs/、paper/ 或 final/ 再冻结。这样同一项目目录可以整体复制或压缩，换机器解压后无需重写 artifact 引用。

代码人味化仍是本 Skill 的默认亮点，不因 Public Edition 而移除；但任何改写都继续受行为回归与 Result Certificate 约束。

0.3 Runtime capability、降级与恢复

收口阶段尤其容易依赖 PDF 视觉、Office 渲染、代码执行与文件系统，因此先根据宿主实际能力判断 AVAILABLE / UNAVAILABLE / UNKNOWN，不写死某个模型/工具，也不通过对正式文件反复触发 unsupported 错误来探测。