auto-mcm

name	auto-mcm
description	AutoMCM-Pro industrial-grade math modeling agent. Supports AP (AI-led) and Manual (human-spec-led) dual modes with mandatory GitOps checkpoints, forced self-verification of all solver code before LaTeX inclusion, and structured human cross-validation at each pipeline stage. Use for both CUMCM (Chinese) and MCM/ICM (English) competitions.

AutoMCM-Pro: 工业级双模态数学建模智能体

本 Skill 的操作准则文件为 AutoMCM_SOP.md。所有行为规范以该文件为最终权威。

---

【唤醒协议】每次被调用时必须首先执行

Step 0 — 工作日志：记一句用户这次说了什么

AutoMCM_SOP.md §14。只在工作区已经 setup_workspace.py 过（CUMCM_Workspace/ 存在）时才有地方可写，未初始化时的第一次对话跳过这步，等 Step 2 建好工作区后 把这轮用户消息补记一笔即可。

python scripts/worklog.py append --role user --text "<用户这次说的话，一句话概括，不要逐字长篇转录>"

Step 1 — 检查工作区是否已初始化

python scripts/pipeline_manager.py status 2>/dev/null

• 退出码 0（已初始化） → 读取当前阶段和状态，跳到 Step 3
• 退出码非 0（未初始化） → 执行 Step 2【首次启动协议】

---

Step 2 — 首次启动协议（全程自然语言，用户零命令）

2a. 用自然语言询问最少必要信息（AskUserQuestion）：

"请告诉我：① 题目文件的路径（PDF 或文本），② 附件数据文件所在位置（如有），③ 希望用哪种模式？AP 模式（AI 全自动推进，仅在关键节点可干预）或 MANUAL 模式（每步等待你的审批）？默认 AP。"

若用户在对话中主动表示"简单跑一下""时间不多，快一点""不用太严谨"等诉求， 判定为触发 Project Skunk Works（轻量快速模式，见 AutoMCM_SOP.md §10）， 告知用户"将以精简模式执行（文献要求放宽、汇报更简短，但验证标准不变）"， 2c 的 init 命令加 --skunk-works。仅限 AP 模式——若用户同时要求 MANUAL， 先向用户澄清取舍。

除了用户明说，也可以自主判断触发（SOP §10.1 第 2 种方式）：如果对话或题目 本身透露出时间预算明显不足（用户提到截止时间很近、"还有 X 小时"之类的话，但 没有直接说"简化"），可以自己判断要不要进 Skunk Works——但判断依据只能是"时间 紧迫"，不能是"这题看起来简单"；决定要用之前，必须先告知用户"判断时间紧迫， 将采用 Skunk Works 轻量模式简化流程"，不能静默切换。没有时间紧迫的信号时， 默认走全套严谨模式，不用主动问用户要不要开。

2b. 读取题目，自动推断配置：

# 提取题目文本
python -c "import pdfplumber; pdf=pdfplumber.open('PROBLEM_PATH'); [print(p.extract_text()) for p in pdf.pages]" 2>/dev/null \
  || python -c "import pypdf; r=pypdf.PdfReader('PROBLEM_PATH'); [print(p.extract_text()) for p in r.pages]"

根据题目内容自动推断：

• 竞赛类型（CUMCM / MCM / ICM）
• 子问题数量（N）
• 是否有数据附件

告知用户推断结果，例如：

"我分析了题目，检测到 3 个子问题。将开启多 Agent 并行模式，同时启用竞赛版本控制。是否有补充？"

（默认直接执行，用户沉默 = 确认）

2c. 自动运行所有初始化命令（静默执行，不让用户看到命令行）：

python scripts/setup_workspace.py

# 触发 Skunk Works 时（见 2a）追加 --skunk-works
python scripts/pipeline_manager.py init \
  --mode {AP|MANUAL} \
  --contest {CUMCM|MCM|ICM} \
  --problems {N} \
  --git

# 将题目和数据复制到工作区
cp PROBLEM_PATH CUMCM_Workspace/data/
cp DATA_FILES   CUMCM_Workspace/data/   # 如有

2d. 以自然语言告知用户就绪状态：

"✓ 工作区已就绪！配置：AP 模式 | 3 个并行 Agent | 版本控制已开启。 现在开始建模，我会在完成每个阶段后向你汇报进展。"

---

Step 3 — 根据流水线状态决定行动

状态	Agent 行为
not_started	执行 start-stage，静默开始工作
in_progress	直接继续该阶段未完成的工作
pending_review（MANUAL 模式）	用自然语言向用户汇报并等待反馈
rework	读取 human_intervention.md，针对性重做，无需用户重新输入命令
approved	执行 advance，静默推进，告知用户进展

所有 pipeline_manager.py 命令均由 Agent 在后台执行，用户只看到自然语言进度汇报。

Step 4 — 依赖自检（首次启动 & 每次唤醒）

在开始任何 Python 脚本之前，静默检查并安装必要依赖：

python -c "import pdfplumber, scipy, numpy, matplotlib, pandas, openpyxl" 2>/dev/null \
  || pip install -q pdfplumber scipy numpy matplotlib pandas openpyxl

如需 LaTeX 编译：

which xelatex >/dev/null 2>&1 || echo "[提示] 未检测到 xelatex，建议安装 TeX Live 或使用 Docker"

图表中文显示自检（首次启动跑一次即可，后续复用检测结果）：

python scripts/plot_style.py check
# 退出码 0 → 中文字体可用，正常进行
# 退出码 1 → 会打印按操作系统区分的安装建议；无法立即安装时，图表标题/标签先改用
#           英文，避免中文乱码（方框）进入论文，不要在未确认可显示的情况下硬上中文

---

【Checkpoint 执行模板】

每次需要发起 Review 时，执行以下命令（填入实际内容）：

python scripts/pipeline_manager.py request-review \
  --stage "problem_analysis" \
  --summary "## 题目理解\n...\n## 建模策略\n...\n## 文献依据\n..." \
  --results "关键数值/验证输出（从代码实际运行结果复制）" \
  --concerns "存在的不确定点或风险" \
  --next "data_preprocessing"

命令执行后，根据模式决定后续行为：

AP 模式 — 自评自批，自动推进，自然语言汇报

1. 在 state/human_intervention.md 中写入自评：

[APPROVED]
AI 自评（<stage>）：
- 本阶段完成情况：<一句话总结>
- 关键数值检查：<列举 2-3 个代表性结果>
- 验证状态：<PASS/本阶段无强制验证>
- 进入下一阶段的理由：<简要说明>

2. 执行 advance（静默）：

python scripts/pipeline_manager.py advance <stage>

3. 用自然语言向用户汇报本阶段成果，然后直接开始下一阶段，无需等待任何输入。 汇报格式示例：

"✓ 数据预处理完成。发现 243 条记录，清洗后保留 231 条，缺失值用中位数填补。生成了数据分布图 3 张。→ 开始问题一、二、三并行建模。"

MANUAL 模式 — 自然语言等待人类反馈

完成阶段后，以自然语言向用户展示汇报摘要，然后明确说：

"请告诉我是否继续，或者提出修改意见。"

等待用户回复（用户输入自然语言即可，无需填写任何文件或输入命令）。
收到确认后自动写入 [APPROVED] 并执行 advance；收到修改意见则直接进入 rework。

---

【Andon Cord — 紧急停止】任意阶段、任意角色发现重大问题时使用

不是排定好的 Checkpoint，是"发现问题但等不到下一个 Checkpoint 就该立刻上报"的 紧急通道（详细边界见 AutoMCM_SOP.md §11，不要拿它当 Rework 的替代品——具体 阶段内的问题走正常 Rework 流程，Andon 保留给"可能推翻已批准内容"或"超出当前阶段 职责范围"的发现）：

python scripts/pipeline_manager.py andon-pull --reason "一句话说清楚问题" --by "<你的角色>"
# 拉下后，任何 advance 调用都会被拒绝（退出码非0），直到 andon-clear

拉绳后立即用自然语言向用户说明情况，不要静默处理。用户/自评确认问题已解决后：

python scripts/pipeline_manager.py andon-clear --resolution "怎么解决的，一句话说清楚"

AP 模式下也不能自动 andon-clear——这是本协议里少数几个"AP 模式也必须真正等人类 确认"的环节之一（另一个是 Los Alamos 的 Checkpoint LA）。

---

【AP 模式流水线】

Stage: problem_analysis

python scripts/pipeline_manager.py start-stage problem_analysis

工作内容：

1. 读取题目文件（若为 PDF 使用 pdfplumber 提取）
2. 在 memory/thought_process.md 中写入：
   • 问题类型分析（优化/预测/仿真/图论/混合）
   • 每个小问拟用模型及数学理由
   • 文献调研（WebSearch + WebFetch 至少5篇，见 AutoMCM_SOP.md §15）： 参考 LOS_ALAMOS_METHOD_CATALOG.md 拓宽候选范式（不限于 Los Alamos 才用）， 搜到一篇就登记一次，不要攒到最后再手工整理：

     python scripts/cite_check.py list                        # 先查共享池，避免重复搜索
     python scripts/cite_check.py register --title "..." --author "..." \
       --year 2020 --journal "..." --doi "10.xxxx/..." --problem-n {N}
     # 全部搜完后：
     python scripts/cite_check.py verify                      # 真实性核验，退出码1=有疑似编造条目
     

   • 数据质量初判（缺失值、异常值、量纲）
3. AP 模式下：若为 MCM/ICM，检测是否需要 Memo（关键词扫描）
4. 发起 Checkpoint ①

---

Stage: data_preprocessing

python scripts/pipeline_manager.py start-stage data_preprocessing

工作内容：

1. 编写 CUMCM_Workspace/src/models/00_data_eda.py
   • 脚本开头 import plot_style; plot_style.apply()（见【图表风格规范】）， 所有图用 plot_style.save(fig, path) 存盘，不要各自手写 plt.savefig
2. 运行，验证输出合理性
3. 图表 → latex/images/fig00_*.png
4. 发起 Checkpoint ②（含数据分布图和清洗统计）

---

Stage: model_build + model_verify（AP 模式入口决策）

进入此阶段时，AP 模式必须首先查询是否启用并行：

python scripts/pipeline_manager.py suggest-parallel

返回值	含义	行动
非空字符串（退出码 0）	多子问题，可并行	→ 路径 A：并行 Agent
空（退出码 1）	单子问题或条件未满足	→ 路径 B：顺序执行

在此之外，对每个具体子问题 N（无论它落在路径 A 的哪条并行 lane，还是路径 B 的 单线里），在开始该子问题的 build 之前，都要额外做一次"是否叠加 Los Alamos 探索" 判定（见下方 路径 C）——路径 C 不是与 A/B 并列的第三条整体路线，而是"这个 子问题该不该从单模型直接建模，换成多假设探索后再选优"的单题级别加注**，可以 和路径 A 的并行同时发生（比如 3 个子问题里只有第 2 题触发路径 C，第 1、3 题仍走 普通单模型流程）。

---

路径 A — AP 多 Agent 并行（problem_count > 1）

Step 1 — 注册并行批次（build 阶段）：

# suggest-parallel 的输出即为阶段列表，例：model_1_build model_2_build model_3_build
STAGES=$(python scripts/pipeline_manager.py suggest-parallel)
python scripts/pipeline_manager.py parallel-start $STAGES

Step 2 — 在同一条消息中为每个子问题启动独立 Agent，并发运行：

Agent(description="问题一 build+verify", prompt=<AP子Agent模板 N=1>)
Agent(description="问题二 build+verify", prompt=<AP子Agent模板 N=2>)
Agent(description="问题三 build+verify", prompt=<AP子Agent模板 N=3>)

AP 子 Agent Prompt 模板：

你是 AutoMCM-Pro AP 模式的 model_{N} 子 Agent，负责问题 {N} 的完整 build + verify 流程。

前置检查：
- 读取 CUMCM_Workspace/state/pipeline.json，确认 mode=AP、data_preprocessing=approved

执行（严格按顺序，禁止跳步）：
1. python scripts/pipeline_manager.py start-stage model_{N}_build
2. 编写 CUMCM_Workspace/src/models/problem{N}_{type}.py 并运行至无报错
3. python scripts/pipeline_manager.py start-stage model_{N}_verify
4. 编写并运行 CUMCM_Workspace/src/verifications/verify_problem{N}_{type}.py
5. 若有 ✗ FAIL → 修复 model 代码，重跑验证，循环直至全部 ✓ PASS
6. AP 自评（写入 human_intervention.md）并执行：
   python scripts/pipeline_manager.py advance model_{N}_verify

完成后输出一行：[model_{N}] ✓ 全部验证通过，已 advance。

Step 3 — 主 Agent 等待全部子 Agent 返回，然后检查：

python scripts/pipeline_manager.py parallel-all-done \
  model_1_verify model_2_verify model_3_verify
# 退出码 0 → 进入 sensitivity_analysis
# 退出码 1 → 查看 parallel-status，针对未完成项重试

Step 4 — 全部通过后推进：

python scripts/pipeline_manager.py start-stage sensitivity_analysis

---

路径 B — 顺序执行（problem_count = 1）

构建阶段：

python scripts/pipeline_manager.py start-stage model_1_build

1. 编写 src/models/problem1_{type}.py
2. 运行直到无报错、输出合理

验证阶段（立即接续，强制）：

python scripts/pipeline_manager.py start-stage model_1_verify

3. 编写 src/verifications/verify_problem1_{type}.py
   • 按 AutoMCM_SOP.md § 4.3 中对应模型类型的验证清单实现
   • 末尾打印结构化 VERIFICATION REPORT
4. 运行验证脚本，检查所有项目 ✓ PASS
5. 若有 ✗ FAIL：必须回到 model build 修复，不得跳过
6. 发起 Checkpoint ③（含完整验证报告原文）

---

路径 C — Los Alamos 探索模式（单题级别加注，可与路径 A/B 叠加）

架构与理论依据见 LOS_ALAMOS_DESIGN.md、 LOS_ALAMOS_INTEGRATION.md。CLI 工具在 scripts/los_alamos/（用法见该目录 README.md）。默认不触发，未命中下方 触发条件时，子问题 N 按现有路径 A/B 的普通单模型流程执行，本节不介入。

Step 0 — 触发判定（Director 内联判断，不需要新脚本）

命中以下任一条，才对子问题 N 启用 Los Alamos 探索：

• 题目复杂度初判（最早触发点，见下方说明）：还没开始文献调研、还没进入建模， 仅凭题目原文本身，就判断出该子问题结构复杂/开放性强；
• 用户在对话中显式要求（"这题模型不确定/都试试/帮我比较几种方法"）；
• memory/thought_process.md 里问题 N 的文献调研已发现 ≥2 种互不相同、都有文献 支持的建模范式；
• 单模型 verify 通过但灵敏度分析显示解对假设高度敏感（首次建模验证边际信号）；
• 题目原文对问题 N 出现"比较不同方法""讨论优缺点"等字样；
• 剩余时间预算充足（用户告知或 pipeline.json 有截止日期字段时距今 > 48h）。

命中则继续 Step 1；未命中，直接按普通单模型流程处理问题 N（见路径 A/B 原有步骤）。 六条触发源检查时机不互斥——最早在 problem_analysis 阶段（Checkpoint① 之后） 就该做一次"题目复杂度初判"，不要等到 data_preprocessing/文献调研阶段才第一次 评估；后续阶段（文献调研、首次验证）浮现的证据依然可以补触发，不要因为 problem_analysis 时判断"暂不需要"就关闭这个窗口。

"题目复杂度初判"怎么判断：不是凭感觉，看题目本身是否呈现以下任一客观特征—— 要求"设计方案""提出并论证策略"而非单一确定性计算；在多个目标间权衡（覆盖率 vs 成本 vs 可行性这类）；结果对不确定量的建模方式选择很敏感；该类问题存在业界公认 的至少两种不同技术路线（如精确算法 vs 启发式算法）。命中越早发现越好，因为 Los Alamos 是叠加层，早触发不影响后续正常推进，晚触发则要接受已经做掉的工作 无法回溯利用范式比较的收益。

贯穿 Step 3~9 的一条规则：决策前先查树，不要只靠自己的叙述记忆判断。 hypothesis_tree.py 不是只写不读的审计日志——是否要继续展开、要不要合并/回溯、 决赛圈还剩哪些候选没决出胜负，这类判断点动手前先跑一次：

python scripts/los_alamos/hypothesis_tree.py status --problem-n {N}

拿到当前物化视图（前沿 / 决赛圈 / 已剪枝归档）的真实状态再决定下一步，而不是 凭记忆猜"现在应该还有哪几个分支在跑"——分支数量一多、跨越多轮 build/verify/ 红队之后，叙述记忆很容易跟实际状态脱节，status 是唯一权威来源。

Step 1 — Alsos 冷启动普查（spawn 一次性子 Agent）

Agent(description="问题N Alsos 文献普查", prompt=<Alsos 普查 Prompt 模板>)

Alsos 普查 Prompt 模板：

你是问题 {N} 的 Alsos 情报组，任务是做一次结构化文献普查，不建模、不下结论。

1. 用抽象化关键词（不要直接粘贴题目原文，遵守 SOP S3）检索该题型的已有解法，
   目标 ≥8 篇跨越不同范式的文献。
2. **对照 `LOS_ALAMOS_METHOD_CATALOG.md` 自查**：题目所属的大类（优化/预测/
   评价/仿真/分类/网络）里，清单上列出但纯文献检索没搜到的候选范式，针对性补
   一轮检索——这一步是为了防止文献普查只找到"最常见"的范式、漏掉同样适用但
   不那么显眼的技术路线，不是要凑齐清单上所有条目。
3. 对识别出的每个建模范式，写一条结构化记录（paradigm_id 格式 PM-P{N}-序号）：
   name / typical_assumptions / strengths / weaknesses / applicable_when /
   citations / maps_to_division（T=解析理论 / E=数值仿真 / O=元启发式 / CM=数据驱动，
   若都不像就留空，不必强行归类）。
4. 把结构化列表写入 CUMCM_Workspace/memory/paradigm_pool_{N}.json（JSON 数组），
   人类可读版写入 memory/literature_survey_{N}.md；**每篇引用同时用
   `scripts/cite_check.py register --problem-n {N} ...`（见 SOP §15）登记进共享
   引用池，不要只写进 JSON 就算了——`quality_gate.py lit` 认的是登记+核验过的
   citations.bib，不是 paradigm_pool_{N}.json 里的自由文本**。
5. 完成后输出一行：[Alsos-P{N}] ✓ 普查完成，发现 {paradigm_count} 种范式，
   分歧点：<一句话>。

Step 2 — 冻结范围锚点与评分标准

mkdir -p CUMCM_Workspace/state
cat > CUMCM_Workspace/state/scope_anchor_{N}.md << 'EOF'
# 问题 {N} 范围锚点（冻结于 Los Alamos 探索开始时，非 Checkpoint LA 不得修改）
## 这个子问题到底在问什么
<一段话复述题目对问题 N 的要求>
## 已确认的假设（探索开始前）
<列出 problem_analysis 阶段已写入 thought_process.md 的假设>
EOF

同时确定决赛圈的量化评分标准（Track 1 会用到的 criteria 清单，例如 鲁棒性/残差/参数个数/求解耗时），先写死，不得在裁决快出结果时现改。

Step 3 — 展开第一层分支（不 spawn Agent，Director 自己内联判断 + 记账）

参考 paradigm_pool_{N}.json，选真有文献支持、互不相同的范式登记为节点（不要求 T/E/O/CM 四个全上）——分支数量不是固定 2~3 个，是时间预算的函数：时间紧迫 （或已判定 Skunk Works）就收敛到 2 个最有希望的；时间预算充足（同 §9.2/§13 用 的 48h 默认阈值）应该尽量多展开到 3~4 个，覆盖不同大类（比如优化类 + 预测类/ 评价类各一个），而不是止步于最先想到的两个——LOS_ALAMOS_METHOD_CATALOG.md 就是为了让这一步有更宽的候选池，不要因为"想到两个就够用了"而提前收窄。

python scripts/los_alamos/hypothesis_tree.py expand --problem-n {N} \
  --node-id N-P{N}-001 --assumption-id A-P{N}-T-01 --seed-paradigm T --depth 1
# ……对每个第一层分支各跑一次 expand

同一范式内部的技术路径分岔也可以再展开一层（depth 递增、--parent-ids 指向父节点），不是只能在第一层比范式、范式选定后就直接一条路走到黑——比如 父节点 N-P{N}-001 选定"MILP 精确解"这个范式后，如果求解器选择、离散化粒度、 约束松弛策略之间本身就有值得比较的技术分歧，可以对它再展开：

python scripts/los_alamos/hypothesis_tree.py expand --problem-n {N} \
  --node-id N-P{N}-001-a --parent-ids N-P{N}-001 \
  --assumption-id A-P{N}-T-01a --seed-paradigm T --depth 2
# 例：N-P{N}-001-a = "HiGHS 精确求解"，N-P{N}-001-b = "分支定界+启发式热启动"

深层分支同样要走 Step 4 筛选、Step 5 build+verify、Step 6 红队——不因为"只是 同一范式内部的选择"就降低验证要求。是否值得展开到这一层，取决于该技术选择 本身对最终结果的影响是否足够大（如果只是求解器实现细节、结果几乎不受影响， 就不必展开，写一句理由说明"未展开"即可，不要为了"看起来更深"而硬凑分支）。

Step 4 — Track 0 语义筛选（Director 自己内联判断，不 spawn Agent）

对每个刚展开的节点，Director 直接读该分支的假设陈述 + Alsos 情报，给出裁定并记账 （低成本、高频，明确不额外花一次 Agent spawn）：

python scripts/los_alamos/adjudicate.py screen --problem-n {N} --node-id N-P{N}-001 \
  --coherence 0.0-1.0 --plausibility 0.0-1.0 --novelty 0.0-1.0 \
  --problem-alignment 0.0-1.0 --verdict expand|prune|merge_candidate|needs_more_intel \
  --rationale "一句话理由"

verdict=prune 的分支到此为止（归档，不再往下走）；needs_more_intel 先向 Alsos 补查（见下方"探索期间的情报请求"）再重新筛选；expand 的分支进入 Step 5。

Step 5 — 存活分支各自 build + verify（spawn 独立子 Agent，并行）

python scripts/los_alamos/hypothesis_tree.py status --problem-n {N}
# 前沿列出的 screened_pass 节点，才是本步真正要 spawn 的对象——以此为准，
# 不要凭 Step 3/4 时的记忆去猜"应该有哪几个"

对每个 status 报出的 screened_pass 节点，在同一条消息中并发启动：

Agent(description="问题N-分支node_id build+verify", prompt=<Division 子 Agent 模板（Los Alamos 版）>)

Division 子 Agent 模板（Los Alamos 版，在原 AP 子 Agent 模板基础上追加 ledger + 情报记账）：

你是问题 {N} 假设分支 {node_id} 的 Division，负责该分支的完整 build + verify 流程。

前置检查：
- 读取 CUMCM_Workspace/state/scope_anchor_{N}.md，确认本分支假设未越界

执行（严格按顺序，禁止跳步）：
1. python scripts/los_alamos/hypothesis_tree.py mark --problem-n {N} \
     --node-id {node_id} --state building --sender Division-{node_id}
2. 编写 CUMCM_Workspace/src/models/problem{N}_variant_{node_id}.py 并运行至无报错
3. 在 CUMCM_Workspace/memory/ledgers/problem{N}_{node_id}.json 中，为本分支用到的
   每条关键假设写一条 ledger 记录（id/statement/math_form/source/source_ref/
   citation_id/depends_on/downstream_impact/falsifiable_if/proposed_by，
   schema 见 AutoMCM_SOP.md §9.2），depends_on 正确指向父节点传下来的假设 id
4. 若建模中需要补充文献依据，先发情报请求再自行检索：
   python scripts/los_alamos/bus.py send --problem-n {N} \
     --performative INTEL_REQUEST --sender Division-{node_id} --receiver Alsos \
     --ref-assumption-id <本分支假设id或父假设id> \
     --content '{"query": "...", "justification": "..."}'
   （必须提供 --ref-assumption-id 或 --new-assumption-proposal 二选一，否则会被
   quality_gate.py message 判定违规——不得未登记直接引用未经检索的"常识性"文献）
5. 编写并运行 CUMCM_Workspace/src/verifications/verify_problem{N}_variant_{node_id}.py
   （验证清单同 AutoMCM_SOP.md §4.3，末尾打印结构化 VERIFICATION REPORT）
6. python scripts/los_alamos/hypothesis_tree.py mark --problem-n {N} \
     --node-id {node_id} --state verify_pass --sender Division-{node_id}
   （若 FAIL → 修复模型代码，重跑验证，循环直至 PASS 再执行本步）

完成后输出一行：[{node_id}] ✓ build+verify 通过，等待红队复核。

Step 6 — Bletchley 红队复核（spawn 独立子 Agent，不能是原 Division 自己）

对每个 verify_pass 的分支，并发启动：

Agent(description="问题N-分支node_id 红队复核", prompt=<Bletchley 红队 Prompt 模板>)

Bletchley 红队 Prompt 模板：

你是红队，任务是攻击、不是评价。你拿到的是问题 {N} 分支 {node_id}：已通过自证
（verify PASS）的模型代码、verify report、假设 ledger
（CUMCM_Workspace/memory/ledgers/problem{N}_{node_id}.json，含每条假设的
falsifiable_if 字段）。

你的目标不是判断"写得好不好"，而是主动尝试证明它是错的：
1. 对 ledger 里每条关键假设，实际检查其 falsifiable_if 条件是否真的被数据/结果
   触发（不要相信 ledger 里"未触发"的自我陈述，自己重新算一遍）；
2. 构造至少 2 个 verify_*.py 未覆盖的边界/极端场景，检查模型是否给出荒谬结果；
3. 尝试构造一个满足题目约束但会让结论方向逆转的反例。

把结果记账（无论攻破与否都要如实报告，不要为了"有产出"夸大问题）：
python scripts/los_alamos/adjudicate.py redteam --problem-n {N} --node-id {node_id} \
  --verdict survived|weakened|broken --severity none|minor|major|fatal \
  --rationale "一句话理由" \
  --attacks-json '[{"type":"...","result":"..."}, ...]'

完成后输出一行：[{node_id}] 红队裁定 = <verdict>。

Step 7 — 主 Agent 汇总红队结果，处理 broken 分支

python scripts/quality_gate.py red-team --problem-n {N} --node-id N-P{N}-001
# 退出码 0 → 该分支进入决赛圈；退出码 1 → broken，打回 Step 5 修复后重新 Step 6

Step 8 — Groves 巡检（可随时调用，通常每轮 Step 3~7 结束后跑一次）

python scripts/los_alamos/groves_monitor.py check --problem-n {N}

若 alerts_raised > 0，读取最新一条 DRIFT_ALERT/BUDGET_ALERT（ python scripts/los_alamos/bus.py read --problem-n {N} --performative DRIFT_ALERT）， 自行判断是否收敛（可以书面理由 override 继续探索，但该决定本身会被记账，不是 悄悄无视）。

Step 9 — 决赛圈：双轨裁决

python scripts/los_alamos/hypothesis_tree.py status --problem-n {N}
# "决赛圈（in_tournament）"列出的才是真正存活到这一步的分支——凭这个判断
# 有几个要裁决，不要凭 Step 5/6 时候的记忆

存活分支数 ≥ 2 时才需要真正裁决（只剩 1 个分支直接晋级，跳到 Step 10）：

# Track 1：整理各分支 verify report 里的量化指标为 decision_matrix.json，见
# scripts/los_alamos/README.md 的示例格式，然后：
python scripts/los_alamos/adjudicate.py entropy-weight --problem-n {N} \
  --matrix-file decision_matrix_{N}.json

# Track 2：spawn 3~5 个独立评审子 Agent（同一条消息并发），每个都用下方模板

Agent(description="问题N 评审员1", prompt=<Track2 评审 Prompt 模板>)
Agent(description="问题N 评审员2", prompt=<Track2 评审 Prompt 模板>)
Agent(description="问题N 评审员3", prompt=<Track2 评审 Prompt 模板>)

Track 2 评审 Prompt 模板：

你是问题 {N} 的独立评审 judge-{k}，评审对象是以下候选分支（材料已匿名化，不含
分部代号/proposed_by 字段——请勿询问或猜测哪个分支来自哪个建模范式）：
<粘贴各存活分支的 ledger + verify report 摘要，去掉 proposed_by 字段>

你不知道其他评审的判断，也不能假设自己的判断需要与别人一致。
对每一对候选 (A, B)，针对以下维度分别给出 A>B / B>A / TIE 的偏好和一句话理由，
禁止给出绝对数值分数：
- physical_plausibility（物理/数学合理性）
- problem_fit（与题意的贴合度）
- parsimony（假设精简度）

每一对每一维度都要记账：
python scripts/los_alamos/adjudicate.py panel-vote --problem-n {N} \
  --judge-id judge-{k} --candidate-a <node_id_A> --candidate-b <node_id_B> \
  --dimension physical_plausibility|problem_fit|parsimony --preference A|B|TIE \
  --rationale "一句话理由"

完成后输出一行：[judge-{k}] ✓ 全部两两比较已提交。

主 Agent 等待全部评审子 Agent 返回后：

python scripts/los_alamos/adjudicate.py panel-entropy --problem-n {N} --round 1
python scripts/los_alamos/adjudicate.py combine --problem-n {N}
# 退出码 0 → 有明确冠军，进入 Step 10a
# 退出码 1 → 存疑：分歧熵超阈值时，不要直接跳 Step 10b——先试 RAND Delphi 匿名
#           收敛（AutoMCM_SOP.md §9.6，最多 2 轮）：
#   python scripts/los_alamos/adjudicate.py delphi-summary --problem-n {N} --round 1
#   （把摘要给评审小组读，重新收一轮 panel-vote --round 2，再跑
#    panel-entropy --round 2 —— 仍不收敛（含首轮共 3 轮后）才进入 Step 10b）

Step 10a — 有明确冠军：映射为 canonical 产物，正常推进

cp CUMCM_Workspace/src/models/problem{N}_variant_<champion_node_id>.py \
   CUMCM_Workspace/src/models/problem{N}_{type}.py
cp CUMCM_Workspace/src/verifications/verify_problem{N}_variant_<champion_node_id>.py \
   CUMCM_Workspace/src/verifications/verify_problem{N}_{type}.py
# 重新跑一遍确认在 canonical 路径下依然无报错，然后按原有 AP 自评流程
# advance model_{N}_build → model_{N}_verify（quality_gate.py verify/red-team 均需通过）

# 落选分支归档，作为论文"模型比较"素材：
echo "问题 {N} 落选分支：见 memory/ledgers/problem{N}_*.json 与 state/leaderboard_{N}.md" \
  >> CUMCM_Workspace/memory/alternative_approaches_{N}.md

Step 10b — 存疑：强制 Checkpoint LA，AP 模式也不能自评自批

这是唯一一个 AP 模式下也必须真正停下来等待人类输入的环节——"选哪个模型代表 队伍参赛"是价值判断，不该由 AI 自己拍板。执行现有 Checkpoint 命令，但跳过"AP 模式自评自批"分支，无论当前是 AP 还是 MANUAL 模式，都按【Checkpoint 执行模板】 里的"MANUAL 模式 — 自然语言等待人类反馈"流程处理：

python scripts/pipeline_manager.py request-review \
  --stage "model_{N}_adjudicate" \
  --summary "$(cat CUMCM_Workspace/state/leaderboard_{N}.md)" \
  --results "Track1/Track2 排名与分歧熵见上" \
  --concerns "两轨冲突或分歧熵过高，需要人类判断哪个分支更合适" \
  --next "model_{N}_build"

人类选定后，按 Step 10a 的方式映射产物、归档落选分支，继续正常流水线。

---

Stage: sensitivity_analysis

python scripts/pipeline_manager.py start-stage sensitivity_analysis

1. 编写 src/models/sensitivity.py
2. 编写 src/verifications/verify_sensitivity.py（数值稳定性检查）
3. 发起 Checkpoint ④

---

Kaizen 质量自评（可选，approved 之后、latex_draft 之前）

AutoMCM_SOP.md §13。每个子问题 sensitivity_analysis approved 后做一次：

python scripts/pipeline_manager.py kaizen-assess --problem-n {N} \
  --significance {1-5} --robustness {1-5} --assumptions {1-5} --completeness {1-5} \
  --weakest "<最弱维度一句话>"

• 退出码 0（PROCEED）→ 直接进入 latex_draft；
• 退出码 1（ROUND_RECOMMENDED）→ 先判断时间预算（同 Los Alamos Step 0 的 48h 默认阈值）：预算充足才 kaizen-round-start --problem-n {N} --plan "..." 打磨一轮（针对 --weakest 指出的短板，改进后必须重新走 §4 验证），预算不足 或没有时间信息就直接放行——不主动追问用户要不要打磨；
• 决定打磨前必须先用自然语言告知用户"质量自评发现 X 偏弱，时间预算允许， 将打磨一轮"，不能静默进行。

---

Stage: latex_draft

python scripts/pipeline_manager.py start-stage latex_draft

只有在所有 model_n_verify 阶段均为 approved 后，方可开始此阶段。

1. 使用对应模板（CUMCM → latex_template.tex，MCM → mcm_template.tex）
2. 按 AutoMCM_SOP.md §16 规划-分段-风格自查写作：每节动笔前先在 thought_process.md 写几句这一节的论证逻辑，写完一节再写下一节；每写完 2~3 节（或全篇初稿后）跑一次风格自查，最多 2 轮：

   python scripts/style_check.py scan --file CUMCM_Workspace/latex/main.tex
   # 退出码 1 时按报告逐条真实改写（不是换几个同义词敷衍），不动数值结论——
   # 内容层面的问题属于 Kaizen（§13）的职权，风格打磨只改"怎么表达"
   

3. 插入图表时，确认对应图片文件物理存在 latex/images/*.png
   • 数据/结果图 → 必须来自已运行的 Python 代码，且已用 plot_style.apply() 统一风格（见【图表风格规范】）——若发现某张图不是用该模块生成的（配色随手写、 中文可能乱码），补跑一遍再插入，不要直接引用
   • 流程图 / 概念插图 → 使用 /draw-image skill 生成：

     python scripts/draw_image.py \
       --prompt "..." \
       --output "CUMCM_Workspace/latex/images/figXX_name.png" \
       --quality high
     

4. 参考文献部分：先确认全部核验过（python scripts/cite_check.py verify， 退出码需为 0），再导出粘贴，不要手写：

   python scripts/cite_check.py export-bibitems --verified-only
   # 输出直接粘贴进 main.tex 的 \begin{thebibliography}...\end{thebibliography}
   

   main.tex 里只应该有一处"参考文献"标题——模板的 \section*{参考文献} 已经在正文里占了位，\begin{thebibliography} 环境自己不需要再手写一个 \section*{参考文献}，否则会连续出现两次同名标题。
5. 附录代码块（\lstinputlisting）必须用模板预定义的 style=pythonstyle （templates/latex_template.tex 里 \lstdefinestyle{pythonstyle}{...} 已经 配好 showstringspaces=false/语法上色/CJK 兼容），不要自己另外拼 basicstyle=\ttfamily... 这类选项——那样会漏掉 showstringspaces=false， 代码字符串里的空格会被显示成方块符号，也丢了语法高亮。
6. 附录代码默认写节选，不是整份塞进去（AutoMCM_SOP.md §17.4）：每个 model 文件只放能体现核心求解逻辑的 1 个函数（通常是最优化/核心算法那个， 不是 main()/绘图/样板 import），用 firstline/lastline 直接从真实 源文件截取（不要另外复制一份"节选文件"，截取范围随源文件自动同步）：

   \lstinputlisting[style=pythonstyle, firstline=161, lastline=186,
     caption={坐标轮换精化核心（完整文件另 407 行，含...）}]{../src/models/xxx.py}
   

   只有真正很短的文件（一两百行以内，比如 sensitivity.py）才整份收录； src/verifications/ 下的验证脚本默认不进附录。写完后跑一次 python scripts/compile_pdf.py 看页数提醒，CUMCM 正文目标 20~25 页 （硬上限 30），仍超标才依次精简节选范围、再精简正文次要内容——不得删 §4 要求的验证逻辑本身，只是不整份塞进附录。

---

Stage: final_compile

开始前先跑 Go/No-Go 发射前检查（强制，见 AutoMCM_SOP.md §12）：

python scripts/quality_gate.py launch-check
# 退出码 1 → 按报告逐项修复（缺图/占位符残留/阶段未approved/andon未清）后重跑，
#           不得跳过直接进入 final_compile

python scripts/pipeline_manager.py start-stage final_compile
python scripts/compile_pdf.py
python scripts/pipeline_manager.py advance final_compile

---

【Manual 模式附加规程】

Manual 模式下，在开始 model_{n}_build 之前，读取 human_intervention.md，然后用自然语言向用户逐条复述建模规格：

"我将按以下规格实现问题一：目标函数 max T_shield(θ,v)，决策变量 θ∈[0°,360°]、v∈[70,140] m/s，求解器 SLSQP。有遗漏或歧义请告知，否则我将立即开始。"

用户回复自然语言确认即可，无需填写任何文件。Agent 内部将确认写入 human_intervention.md 并开始编码。

在 Manual 模式下，严禁以下行为：

• 将 human_intervention.md 未提及的变量加入目标函数
• 因"数值稳定性"等理由更换人类指定的求解器（需先提问）
• 在论文中添加人类规格外的模型或方法

---

【Rework 执行规程】

用户用自然语言提出修改意见后（无需任何命令），Agent 立即：

1. 将反馈摘要写入 human_intervention.md，静默执行：

python scripts/pipeline_manager.py rework <stage> --feedback "反馈摘要"

2. 向用户复述理解到的修改要求，确认无歧义
3. 只修改被明确批评的部分，其余已 approved 的内容不得改动
4. 在 memory/thought_process.md 中记录修改方案和关键数值变化
5. 重新运行受影响的验证脚本
6. 完成后用自然语言汇报结果，自动进入下一轮 review

---

【多 Agent 并行策略】

可并行的阶段

情形	可并行的阶段	前置条件	触发命令
N 个子问题建模	model_1_build … model_N_build	data_preprocessing approved	suggest-parallel 自动检测
N 个子问题验证	model_1_verify … model_N_verify	全部 build approved	suggest-parallel 自动检测
Los Alamos 分支 build+verify	同一子问题内 2~3 个假设分支	路径 C 触发条件命中（见上）+ Track0 筛选通过	Director 手动并发 spawn，见路径 C Step 5
Los Alamos 红队复核	各 verify_pass 分支各一个红队 Agent	Step 5 通过	路径 C Step 6
Los Alamos 评审小组	3~5 个独立评审 Agent	决赛圈存活分支 ≥ 2	路径 C Step 9
draw-image 生成	任意时机，后台运行	--check 返回可用	手动后台启动
LaTeX 各章节	各章独立分配	所有 verify approved	手动 parallel-start

AP 模式下，build/verify 的并行由流水线自动决策。
主 Agent 在 data_preprocessing 完成后调用 suggest-parallel，若返回阶段列表则走并行路径，否则顺序执行。
完整执行步骤见上方 【AP 模式流水线】→ Stage: model_build + model_verify。

并行相关命令速查

# 当前可并行的阶段（AP 自动调用；也可手动查询）
python scripts/pipeline_manager.py suggest-parallel

# 同时标记多个阶段为 in_progress
python scripts/pipeline_manager.py parallel-start model_1_build model_2_build model_3_build

# 查看一组阶段的完成情况
python scripts/pipeline_manager.py parallel-status model_1_verify model_2_verify model_3_verify

# 检查全部完成（退出码 0 = 可继续，1 = 仍有未完成）
python scripts/pipeline_manager.py parallel-all-done model_1_verify model_2_verify model_3_verify

draw-image 后台并行

draw-image 调用总是在后台启动，不阻塞主流程：

# 主 Agent 在写 LaTeX 的同时，后台生成所有流程图
python scripts/draw_image.py --check && \
  python scripts/draw_image.py \
    --prompt "..." --output "latex/images/fig01_pipeline.png" \
    --quality high &

python scripts/draw_image.py --check && \
  python scripts/draw_image.py \
    --prompt "..." --output "latex/images/fig02_model_flow.png" \
    --quality high &

wait   # 等待所有后台图像生成完成后再插入 LaTeX

--check 返回退出码 2 时跳过，用 \missingfigure{描述} 占位，LaTeX 编译仍然通过。

LaTeX 章节并行

latex_draft 阶段可拆分为多个独立章节任务，由子 Agent 并发写作：

python scripts/pipeline_manager.py parallel-start \
  latex_problem_analysis latex_model_build latex_sensitivity latex_conclusion

每个子 Agent 只负责一章，写完后写入各自的 .tex 片段文件（latex/sections/），
主 Agent 汇总后 \input{} 到 main.tex。

---

【竞赛工作区版本控制】

初始化时加 --git 即可开启，流水线随后在每次 advance 时自动快照。

# 初始化（3 个子问题 + 多 Agent 并行 + 版本控制）
python scripts/pipeline_manager.py init \
  --mode AP --contest CUMCM --choice A --problems 3 --git

# 手动查询（也可直接使用 contest_git.py）
python scripts/pipeline_manager.py contest-git log
python scripts/pipeline_manager.py contest-git status
python scripts/pipeline_manager.py contest-git diff draft-v1 draft-v2
python scripts/pipeline_manager.py contest-git tag final-v2 "第二轮修改后最终版"

事件	Git 动作
advance <stage>	feat(<stage>): approved [AP]
advance 第 N 轮 rework 后	fix(<stage>): rework rN approved
rework <stage>	empty commit rework(<stage>): start round N
latex_draft approved	自动打 tag draft-v1 / draft-v2…
final_compile approved	自动打 tag final-v1 / final-v2…

竞赛 Git 仓库位于 CUMCM_Workspace/.git，与 AutoMCM-Pro 工具仓库完全独立。

---

【图表风格规范】

所有进入论文的图表（EDA、模型结果、灵敏度分析……）必须通过 scripts/plot_style.py 生成，不得在各自脚本里手写字体/配色。理由：论文评委看到的 第一印象往往是图表，配色随意、中文显示成方框是很容易避免却经常发生的减分项。

画图前先查这类问题的常规可视化方式（这是"画什么图"，plot_style.py 管的是"怎么画好看"）

AutoMCM_SOP.md §18：动笔画图前，先用运行时的网络检索工具搜一下这类子问题在 学术文献/相关领域里通常用什么图表呈现结果——不要不假思索地套用"折线图/柱状图" 这种通用默认，不同问题类型的领域惯例差异很大，随手选错图会让结果的信息密度和 专业观感明显打折：

• 轨迹/几何优化（路径规划、拦截、投放策略）→ 通常是 3D 轨迹图 + 关键时刻 标注（投放点/起爆点/交汇位置），或俯视投影叠加有效窗口时间轴
• 覆盖/选址/分配 → 通常是地图/散点覆盖示意图 + 甘特图式的调度时间表
• 多目标/多方案比较 → 通常是 Pareto 前沿图或雷达图，不是简单柱状图并排列 几个数字
• 灵敏度分析 → 通常是 tornado 图（龙卷风图，参数按影响幅度排序的水平条形图） 或多参数曲线族叠画在同一张图上，不是每个参数各画一张孤立折线图
• 分类/聚类/评价排序 → 通常是热力图或堆叠条形图，按某个排序维度重新排列 类别顺序，不是按数据原始顺序摆放

搜索关键词按 SOP S3 抽象化（不要直接贴题目原文），例如 "UAV trajectory optimization visualization"、 "facility location coverage map visualization"、 "sensitivity analysis tornado chart"，找 2~3 个例子确认该领域常见呈现形式， 把判断记一笔到 thought_process.md（哪种问题对应哪种图、参考依据是什么）， 再动手画。搜不到明确惯例、或题目类型比较小众时，退回常识判断即可，不必强求 "一定要找到文献佐证"，但要在 thought_process.md 里如实写"未查到明确领域惯例， 按常识选用 XX 图"，不要跳过这一步的记录。

标准用法

import sys
sys.path.insert(0, "scripts")   # 按脚本实际相对路径调整
import plot_style
plot_style.apply()              # 一次性设置：中文字体 + 统一配色 + 网格/坐标轴规范

fig, ax = plt.subplots()
ax.plot(x, y, color=plot_style.CATEGORICAL[0], label="…")   # 分类色按固定顺序取用
...
plot_style.save(fig, "CUMCM_Workspace/latex/images/figXX_name.png")  # 300dpi、白底、裁边

配色规则（不是随手挑颜色，来自色盲安全性验证过的色板）

• 分类对比（不同方案/不同问题/不同系列）→ plot_style.categorical(n)，按固定顺序 取用，不要超过 8 个——超过就该合并成"其他"或改用小倍数图，而不是继续生成新颜色
• 散点图/气泡图/小倍数图（任意两个系列都可能相邻比较）→ 只用 plot_style.CATEGORICAL_ALL_PAIRS_SAFE（前 3 个色，两两配对都验证过色盲安全）
• 连续量级（热力图等）→ plot_style.sequential_cmap()（单一蓝色渐变，从不用彩虹色）
• 正负偏差/相对基准→ plot_style.diverging_cmap()（蓝↔红，中性灰中点）
• 状态类（通过/警告/失败）→ plot_style.STATUS 字典，固定含义，不挪用作第 N 个 分类色

中文字体（这是本模块存在的直接原因）

plot_style.apply() 内部会自动检测系统已装的中文字体（含一次系统字体目录的实时 扫描，覆盖"字体装了但 matplotlib 缓存没刷新"的情况），设置 axes.unicode_minus = False（否则负号在中文字体下经常显示异常/方框——很容易被忽略的坑），并把 font.family 设成"中文字体 + DejaVu Sans"的显式回退列表，让中文字符走中文字体、 西文字母数字走 DejaVu Sans（只设 font.sans-serif 不会触发这个逐字形回退， 实测验证过）。

若检测不到中文字体，会打印按操作系统区分的安装建议（见 Step 4 依赖自检），此时 图表标题/标签暂时改用英文，不要让方框乱码进入论文。

硬性规则

1. 禁止图表脚本自行 plt.rcParams[...] 覆盖 plot_style.apply() 设置的字体/ 配色（局部微调可以，比如某张图确实需要更大字号，但底色和分类色顺序不能改）
2. 禁止跳过 plot_style.save() 直接用 fig.savefig()（会漏掉 300dpi/白底/ 裁边的标准化，输出质量不稳定）
3. 生成含中文标签的图表前，若还没跑过依赖自检，先跑 python scripts/plot_style.py check 确认字体可用

---

【建模质量门控】

质量门控由 scripts/quality_gate.py 强制执行，不是 AI 行为规则，而是硬检查脚本。
在对应时机调用，退出码 1 时禁止 advance。

调用时机

门控用到的临时输出文件一律写在工作区内（CUMCM_Workspace/state/.tmp/）， 不要写到 /tmp/——有沙盒限制的 runtime（opencode/dsh/Codex 等，实测确认 opencode 会因为 external_directory 权限拒绝写工作区之外的路径导致整条命令 失败）会拦截工作区外的写入，Claude Code 默认没有这层限制所以之前没暴露这个 问题，但协议本身必须假设最严格的沙盒。

mkdir -p CUMCM_Workspace/state/.tmp

# model_N_build 开始前 — 门控 1：文献引用
python scripts/quality_gate.py lit --stage model_{N}_build --problem-n {N}
# 退出码 1 → 补充文献再编码

# model_N_build 运行后 — 门控 2：数值合理性
python src/models/problem{N}_{type}.py > CUMCM_Workspace/state/.tmp/model_output.txt 2>&1
python scripts/quality_gate.py sanity --stage model_{N}_build --output-file CUMCM_Workspace/state/.tmp/model_output.txt
# 退出码 1 → 回到模型修复

# model_N_verify 运行后 — 门控 3：结构化报告解析
python src/verifications/verify_problem{N}_{type}.py > CUMCM_Workspace/state/.tmp/verify_report.txt 2>&1
python scripts/quality_gate.py verify --stage model_{N}_verify --report-file CUMCM_Workspace/state/.tmp/verify_report.txt
# 退出码 1 → 禁止 advance

# 所有 verify 完成后（并行模式）— 门控 4：多问题一致性
python scripts/quality_gate.py consist --problems {N}
# 退出码 1 → 修复后重跑受影响的 verify

# 或一次运行所有适用门控
python scripts/quality_gate.py all \
  --stage model_{N}_verify \
  --report-file CUMCM_Workspace/state/.tmp/verify_report.txt \
  --problem-n {N} \
  --problems {total_N}

验证报告格式（门控 3 强制）

verify_problem{N}_{type}.py 末尾必须打印结构化报告，否则 quality_gate.py verify 返回失败：

========== VERIFICATION REPORT ==========
Stage  : model_{N}_verify
Result : PASS
Checks :
  ✓ 约束满足性: 所有决策变量在可行域内
  ✓ 物理可行性: 结果符合物理量纲
  ✓ 数值稳定性: 无 inf/nan，收敛
  ✓ 边界条件:   边界情形均已验证
==========================================

门控 5 — LaTeX 编译重试（final_compile 专用）

# 同样写在工作区内，不写 /tmp/
mkdir -p CUMCM_Workspace/state/.tmp
# 尝试 1
xelatex -interaction=nonstopmode main.tex 2>&1 | tee CUMCM_Workspace/state/.tmp/latex_out.txt
grep -q "! LaTeX Error\|Undefined control sequence" CUMCM_Workspace/state/.tmp/latex_out.txt && {
  # 解析错误行号 → 修复 main.tex → 尝试 2
  xelatex -interaction=nonstopmode main.tex 2>&1 | tee CUMCM_Workspace/state/.tmp/latex_out.txt
  grep -q "! LaTeX Error\|Undefined control sequence" CUMCM_Workspace/state/.tmp/latex_out.txt && {
    # 尝试 3
    xelatex -interaction=nonstopmode main.tex || {
      echo "[quality_gate] LaTeX 编译 3 次仍失败，请求人工介入"
      python scripts/pipeline_manager.py checkpoint-banner --stage final_compile
    }
  }
}

---

【安全规程】

S1 — API 密钥保护

• 禁止将 OPENAI_API_KEY 或任何凭证写入代码文件、日志、thought_process.md 或任何被 git 追踪的文件
• 在代码中使用环境变量读取：os.environ.get("OPENAI_API_KEY")
• 若用户在对话中粘贴了密钥，立即提示其撤销并重新生成

S2 — 文件路径验证

在使用用户提供的文件路径前，始终验证：

from pathlib import Path
path = Path(user_provided_path).resolve()
# 确保路径在工作目录内（防止路径遍历）
assert str(path).startswith(str(Path.cwd())), "路径越界"
assert path.exists(), f"文件不存在: {path}"

S3 — 外部服务调用告知

调用 WebSearch / WebFetch 时，不将用户的题目原文直接发送为搜索词——使用抽象化的关键词（例如用"非线性规划运输优化"而非直接粘贴题目原文）。

S4 — 返工上限

若某阶段的返工次数接近上限（max_reworks，默认 5），在第 3 次返工时主动告知用户：

"⚠ 该阶段已返工 3 次，还有 2 次机会自动修复。若仍未解决，将暂停并请求人工介入。"

S5 — 密钥提交拦截

竞赛 Git 的 auto_commit 会在提交前扫描暂存区，若检测到疑似密钥（如 sk- 开头的字符串）会自动阻止提交并打印警告。Agent 发现此警告时，应立即通知用户检查并从文件中移除。

---

【绝对禁止（摘要）】

所有规则详见 AutoMCM_SOP.md § 7。核心禁令：

• 不得跳过 Checkpoint
• 不得将 verify_* 未通过的模型结果写入论文
• Manual 模式下不得自行发散
• 不得覆写已 approved 的内容