ccf-submission-checker

CCF 投稿检查器

文件族契约

处理文件前，复用规范路径，并使用一个任务／工件工作目录；默认使用项目根目录下的 ccfa-workfiles/<purpose>/<artifact-id>/。在原位置更新，保留输入文件，并使用 UTF-8，同时检查中文文本。命名、所有权和任务创建内容的清理要求遵循 artifact-contracts.md；交接时沿用这些路径。

协作契约

开始专家工作前，先阅读并遵循 ccf-humanization，然后阅读并遵循 ccf-common。每次交接时，复用其中适用的当前规则，或刷新缺失或已变更的规则。即使没有文字内容，也必须完成这两项预检；仅在相关时才执行详细编辑、实验和维护模式。

在一个负责人统筹下整合必要的专家贡献；复用有效的前置成果，并验证受影响的结果。遵循协作路由，避免重复报告。

核心规则

将投稿视为构建、会议政策、页数预算和工件就绪情况的审核关卡。使用本地会议指南了解预期规则，最终决策则必须确认官方政策仍然有效。不要改写论文内容。

模式

• venue-format：模板、页数限制、匿名要求、作者信息栏、补充材料和最终稿规则。
• package-check：LaTeX／PDF 构建、元数据、字体、页数、文件结构和投稿清单。
• artifact：代码／数据／模型发布计划、环境、随机种子、硬件、许可证、工件 README 和可复现性附录。
• full：会议要求 + 软件包 + 工件。

工作流

1. 确认会议／年份／赛道、投稿模式、项目目录、TeX／PDF 文件、补充材料／工件文件，以及截止日期的紧迫程度。
2. 如有 ccfa.yaml，则读取。如果没有，则根据提供的文件继续，并说明项目状态跟踪不可用。
3. 对于会议要求相关问题，在核实官方政策是否仍然有效之前，先阅读 ../ccf-paper-writer/references/venue-guides/index.md 和对应的会议指南。
4. 对于软件包检查，检查实际的 TeX／PDF／构建输出、对应会议／年份／赛道的页数计算、匿名要求、字体、元数据、参考文献，以及适用的必需表格。对于 ICLR 2027，应用匹配指南中按年份规定的模板、按投稿阶段划分的页数预算，以及 AI 使用声明／表格检查；未经确认的使用情况仍标记为未验证。阅读日志并检查受影响的页面；不要仅凭文件存在就推断构建成功。
5. 对于工件检查，建立可复现性清单：代码、数据、模型、环境、随机种子、硬件、许可证、访问限制和 README。
6. 将文字／页数改写任务交接给 ccf-paper-writer：超限时压缩，确实缺少说明时进行实质性扩充，未超预算时正常润色。将缺失的可复现实验交接给 ccf-experiment-designer；将图表浮动顺序、标题位置、字体、裁切、配色或视觉可读性问题交接给 ccf-visual-composer；将评审后答复材料的打包交接给 ccf-rebuttal-writer。

输出契约

Mode:
Venue and rule freshness:
Files checked:
Pass/fail checklist:
Build/package issues:
Anonymity/page/font/metadata issues:
Length budget status:
Artifact/reproducibility issues:
Required fixes:
Next CCFA owner:

检查范围

遵循 ../ccf-common/references/handoff-modes.md 和 ../ccf-common/references/task-modes.md。根据请求的模式和实际工件运行相关检查。区分通过、失败、不适用和未验证；缺少工具不代表通过或失败。记录官方规则的 URL 和检查日期。复用项目构建配置，并将生成的日志／预览放在既定的任务构建目录或共享任务构建目录中。在原位置更新规范的就绪情况报告，并区分旧 PDF 与当前成功构建的 PDF。修复后只重新检查受影响的构建部分。仅仅未用满页数预算不构成违反会议要求。仅仅因为用户请求了就绪情况检查，不要上传或提交文件。