mathmod-full-pipeline

name	mathmod-full-pipeline
description	数学建模竞赛统一全流程 Skill：从只有题面/附件开始，完成审题锚定、数据体检、问题依赖图、 分层方法检索与可执行 recipe、自适应策略竞赛、低成本诊断实验、Agent task 消费协议、代码实跑、 结果与论文生成、证据登记、独立验收、依赖感知修复、格式检查和发布。当用户要写数模论文、 完整解决 CUMCM/MCM/ICM/研赛题、生成结果文件、审查或升级已有数模项目、终稿验收、 数模全流程 Agent 时使用。适用于从零 forge、已有项目 audit/repair、最终 finalize； 双交付物、compute-first、fail-closed、状态可恢复。

MathMod Full Pipeline

定位：一套统一的数模竞赛 Agent Harness。mathmod-full-pipeline 是唯一 control plane；它包含三层，严格分权：

1. Execution Orchestration：规划 ANALYST→PROBER→COMPUTER 的探索、问题依赖、重开与修复范围；由 scripts/mathmod_orchestrator.py 管理。
2. Agent Runtime Protocol：Agent 从 execution_plan 领取 READY task、获得最小知识包、claim、提交 handoff、触发 reopen；由 scripts/execution_protocol.py 管理。
3. Validation State Machine：对已落盘输入、结果、证据、论文与提交物执行 S0-S9 fail-closed 验收并生成唯一发布凭据 release_manifest.json；由 scripts/mathmod_pipeline.py 管理。

orchestrator/protocol 可以规划、调度、失效、恢复，但不得伪造 PASS 回执或写 release credential；最终发布权只属于 validation pipeline。knowledge_router.py 是纯事实解析 library，不持有 scheduler、task state、DAG transition、validator gate 或 release 权力。当前 task runtime 以 canonical QID:ROLE:action + stage 为规范语义；通用 capability/provider 路由等到存在经过运行验证的多 provider 需求后再设计。

宿主边界与中控 MCP

任何宿主前端（ZCode / Codex / DSH）都是同一个 mathmod Core 的薄前端，不新增 scheduler、状态库、validator 或发布权：

• MCP-first：当 mathmod MCP server 可用时，一切会写/迁移动 canonical 状态的操作（task 领取与提交、策略与失效、正式产物与计算、评审生命周期）一律走 mcp__mathmod__* 工具（inspect、next_task、claim、complete、fail、put_canonical_artifact、compute_run、orchestrate、pipeline_action、review_*）。
• 禁止旁路：不得通过 shell/Edit/Write/patch 直接创建、修改或删除 .mathmod/ 下任何规范状态文件；不得直接执行 scripts/execution_protocol.py、scripts/mathmod_orchestrator.py、scripts/mathmod_pipeline.py 等 Core 入口来迁移状态。宿主 PreToolUse guard（.codex/hooks/mathmod_guard.py）会拒绝这些调用。
• 当前事实只从 inspect 读：禁止重放 events.jsonl 推断当前状态；.mathmod/events.jsonl 仅是 append-only 历史，不参与判定。
• 评审 barrier：next_task 返回 REVIEW_REQUIRED 时停止领取新任务，按 references/review-protocol.md 走 review_open → bind_snapshot → review → ingest → resolve/apply → close。
• 只读路径不受限：knowledge_router.py 检索、check_* 检查器等纯读操作仍可直接调用；.mathmod 之外的普通项目产物照常可写。
• 阶段投影：对 Agent 的执行轮次按 macro phase（A_MODEL/B_COMPUTE/C_WRITE/D_RELEASE）组织；S0-S9 仍是唯一规范阶段语义，macro phase 不是第二状态机。

入口路由

输入状态	模式	动作
只有题面/附件	forge	init → bootstrap → S0/S1 锚定 → plan → protocol 驱动执行 → S0-S9 验收
已有代码、结果或论文	audit	不改源产物，运行完整性与质量审计
用户要求修复	repair	生成 dependency-aware repair plan，按 P0→P1→P2 修根因并只重跑影响闭包
中断后继续	resume	读取当前状态、失效记录、execution plan/state，继续 READY tasks
准备提交	finalize	强制固定命名 Word+PDF、结果文件、独立验收和支撑包全绿

CLI（仅无 mathmod MCP 的宿主或人工调试使用；有 MCP 时按上文宿主边界走 mcp__mathmod__*）：

python3 scripts/mathmod_pipeline.py init --root PROJECT --contest CUMCM --year 2026 --problem A --questions 4
python3 scripts/mathmod_orchestrator.py bootstrap --root PROJECT
python3 scripts/mathmod_orchestrator.py plan --root PROJECT
python3 scripts/execution_protocol.py init --root PROJECT
python3 scripts/execution_protocol.py next --root PROJECT --role ANALYST
python3 scripts/execution_protocol.py claim --root PROJECT --task-id Q1:ANALYST:anchor --worker analyst-01
python3 scripts/execution_protocol.py complete --root PROJECT --task-id Q1:ANALYST:anchor --worker analyst-01 --result-json /tmp/handoff.json
python3 scripts/mathmod_orchestrator.py invalidate --root PROJECT --question Q1 --from-stage S2 --reason "route changed"
python3 scripts/execution_protocol.py apply-invalidation --root PROJECT
python3 scripts/mathmod_orchestrator.py repair-plan --root PROJECT
python3 scripts/mathmod_orchestrator.py resume --root PROJECT
python3 scripts/mathmod_pipeline.py audit --root PROJECT
python3 scripts/mathmod_pipeline.py finalize --root PROJECT --support-zip PROJECT/submission/support.zip
python3 scripts/mathmod_pipeline.py status --root PROJECT

不可违反的原则

1. COMPUTE-FIRST：任何最终结果数字先由正式代码实跑并进入登记簿，再进入论文。
2. 探索与发布分离：PROBER 可做 cheap probe，但 probe 数字绝不能直接升级为最终主张；正式数字必须由 COMPUTER 重跑登记。
3. 执行完成不等于验证通过：task DONE 仅表示角色 handoff 完成；S0-S9 PASS 必须由 validator 从磁盘重验。
4. 双交付物：论文 Word/PDF 与磁盘上的结果文件同为评分对象，任一未验收不得给获奖档位。
5. 正向完整性证明：空规则、空主张、空审查矩阵、Markdown-only、缺支撑包均不得发布。
6. 单一事实源：同一方案对象、随机过程、导出函数和提交入口只能各有一份。
7. 独立验收：最终验收器不得与结果生产器同源；必须回读磁盘文件重新计算。
8. 定向修订：禁止无指令整篇重写；新数字先补计算与登记，再改正文。
9. 来源分级：规则强度必须绑定来源权威；第三方经验不能自动升级成官方 MUST。
10. 强约束限制错误空间，不限制思考空间：不得把“预测题必用 X / 每问必须两个模型 / 必须堆创新”写成硬规则。
11. 多模态优先：扫描题面、PDF 页面、公式、图表和模板视觉结构用多模态检查；缺 OCR CLI 不等于不可处理。

Canonical Stage Ontology

当前唯一规范阶段 ID 为 S0-S9，定义见 references/knowledge/stage-ontology.yaml。旧资料中的 G4/G5/G6 或旧版 S1-S5 仅是历史标签；只能按功能语义映射，不能驱动当前状态机。

S0-S9 状态机

S0 INGEST

读取题面原文、附件、官方结果模板和竞赛规则。图片/扫描 PDF 逐页多模态检查。 产出：project.yaml、.mathmod/input_manifest.json。每个输入记录路径、sha256、类型、来源。

S1 ANCHOR

产出基础四件套：

• .mathmod/problem_card.yaml：每问原句、输出粒度、显式约束、语义红线。
• .mathmod/data_card.json：脚本枚举所有文件/Sheet/列/样本/缺失/单位，禁止手写猜测。
• .mathmod/constraint_registry.yaml：题面约束的唯一数学运营定义及求解/落地/验收映射。
• .mathmod/external_anchor.md：官方评阅点、优秀路线和可核验来源；无网络则明确降级。

同时维护执行层四类对象：

• .mathmod/question_graph.yaml：问题 DAG；每问声明 depends_on / consumes / produces。
• .mathmod/problem_signature.yaml：目标、决策类型、时间结构、不确定性、关系结构、数据量与每问风险维度。
• .mathmod/ambiguity_registry.yaml：保留题意歧义、候选解释、选定解释、证据及“选错后果”。
• .mathmod/assumption_ledger.yaml：假设类型、证据、影响问题、是否需要敏感性检验。

S1 未齐禁止冻结正式建模路线。题意/数据/约束存在高风险歧义时，不得靠模型名猜答案，应进入 PROBER cheap probe。

S2 STRATEGY RACE & PROBE LOOP

分层检索由 scripts/knowledge_router.py 实际执行：

problem_signature → method family → candidate/selected methods → executable recipe → failure patterns → audit

方法节点来自 references/knowledge/method-library.yaml；method→recipe 映射在 references/knowledge/recipe-index.yaml；具体 recipe 位于 references/recipes/。若有效 signature 仍大量 unknown，路由器返回空方法包并标记 needs_signature_probe，禁止随便猜家族。

策略竞赛宽度由 ambiguity × consequence × model_uncertainty 自适应决定：

• low：1 条 formal route；baseline/control 另列，不计 formal width。
• medium：2-3 条 formal routes + 至少一个 cheap probe。
• high：3-5 条 formal routes + cheap experiments 消歧后再冻结路线。

Recipe 不是“模型教程摘要”，而是可执行专家程序，至少包含适用/反适用 signature、design/formulation steps、diagnostic probes、implementation invariants、validation、stop conditions、fallback。ANALYST/PROBER/COMPUTER 按角色投影读取不同字段，不把整库塞入上下文。score_method() 只消费 method-routing.yaml 的 positive/negative/hints；method-library 的 use/avoid 是人工摘要，recipe signature 保持专项语义。

候选评分至少覆盖：语义适配、数据支撑、验证难度、计算成本、失败风险、fallback。创新来自问题结构、证据或验证增量，不以模型堆叠替代适配性。

路线冻结是机器硬门。knowledge_router.validate_strategy_route() 是 protocol、knowledge bundle diagnostics 与 S2 validator 共用的唯一语义解释器。每问 route 使用 baselines[] 记录 baseline/control，使用 candidates[] 记录 formal routes；旧 candidates 中只有明确标记为 baseline/control 的条目会被保守识别。formal width 来自当前 plan 的 strategy_width，baseline 不计数且不可被选为正式路线。formal candidate 使用 id、method_id（读取时兼容旧 method）、fit/data_support/validation/cost/risk/fallback、routing_evidence_ids、probe_evidence_ids、rejection_reason。evidence 必须是去重字符串数组；routing evidence 必须非空且可由当前 Q signature/routing facts 重算，probe 必须存在并属于同一 Q。冻结时 selected formal route 的 rejection reason 只接受 None 或空字符串，其他 formal routes 必须有非空拒绝原因。

ANALYST:strategy 的 complete 规则按风险执行：low 必须提交可冻结的 formal selection；medium/high 仅在 formal candidate set 本身完整、满足 width/evidence 且没有其他 route 错误时，才可暂时不选并解锁 diagnostic_probe。ANALYST:reconsider 没有结构有效的 reopen 时必须冻结；reopen 只接受 S1/S2 和 strip 后非空的 reason。旧 plan 缺显式 role/action/risk_band 时分别从 task ID 与同问 probe task 推导；若显式字段与 task ID 冲突，则作为 plan corruption fail closed。

ANALYST complete 会把当前 proposal 转成 route 内的 selection：candidate ID 是规范 selection identity，method ID 从 candidate 派生；selection 绑定来源 task/attempt、当前 question 的 strategy epoch、evidence、当前 Q route hash、合并后的 Q signature semantic hash，以及该 selected route 引用的同问 probes semantic hash。execution-state 的 DONE source task 保存同一组快照；S2 只用当前 route + execution truth 复核，不读取 event 放行。.mathmod/events.jsonl 中的 strategy_selection 仅是完成 state 提交后的观察历史；缺失、伪造、孤儿或追加失败不影响当前判定，也不做 event replay。旧 artifact 不补造 current provenance。

前半程允许真实循环：

S1 ANCHOR ⇄ S2 STRATEGY ⇄ PROBER

PROBER 发现单位/语义/约束/假设问题时可 reopen=S1；发现候选路线适用性变化时可 reopen=S2。reopen 会创建新的 validity epoch，立即撤销旧 release credential，按 restart plan（.mathmod/restart_plan.json，由 invalidate 写入）中每问各自的 restart_stage 重置 task，并清除受影响 route 的当前 selection；question strategy epoch 持久化在现有 validator state，invalidation intent 文件缺失也不会退回 initial。直接 orchestrator invalidate 后必须运行 protocol apply-invalidation，同一 invalidation ID 重复 apply 是幂等操作。审查类修复建议由 repair-plan 写入独立的 .mathmod/review_repair.json，永不覆盖可执行意图。

RUNNING task 持有租约（lease_id/lease_expires_at）：worker 崩溃后用 protocol reclaim --task-id --expected-attempt N 回收过期租约；init --force 只被活跃租约阻止。execution plan 绑定 planning_inputs 指纹（question graph / signature / ambiguity / assumption 四文件）；anchor 之外的 task 在输入变化后 claim 会得到 PLAN_STALE_REBUILD_REQUIRED，重跑 orchestrator plan 重编译即可。状态迁移按输入是否变化分级：未变化全量保留；已变化只保留 anchor DONE，post-S1 DONE 重置为 PENDING（同 task_id 不代表旧 handoff 仍适用），且活跃非 anchor 租约会直接拒绝重编译。WRITER 等下行角色缺证据时走 .mathmod/work_requests.json（orchestrator work-requests --consume 统一转成 invalidation），不得自行改执行图。

S3 COMPUTE

先建最小基线，跑通数据→模型→结果链；再做增强。正式计算必须经 scripts/compute_runner.py 启动精确 argv。runner 在 subprocess 完成后写 receipt，绑定 run ID/nonce、问题范围、cwd、起止时间、退出码、环境摘要、inputs、完整 src/ 文件图/source-tree hash 与 outputs，再更新 run manifest。磁盘 receipt 只用于审计；S3 生成仅存在于 validator 进程/child environment 的 nonce，重新启动声明的精确 argv，并在该 subprocess 返回后重算 input/code/output。input/code/output 路径不得重叠，代码限定在 src/，输出不得位于 src/ 且必须映射 result contract 的 canonical result artifact。手写 status=success row 或 receipt 不形成运行权威。

COMPUTER 优先读取 selected method 的 recipe：按 implementation 顺序实现，执行 recipe 中必要的正式 validation；命中 stop condition 时不得强行输出成功结论，应记录失败并走 fallback/reopen。

COMPUTER:compute 的 claim 是机器硬门：在 project protocol lock 内 refresh DAG、确认 READY、构造 packet/knowledge，再用统一 route validator 重验当前 formal selection，并核对 packet diagnostics 的 selected candidate/method 与 Q-scoped route/signature/probe 哈希。任一 packet/guard 失败时，task 保持 READY，attempts/worker_id/claimed_at 不变；全部通过后才原子替换 execution-state row 为 RUNNING 并记录 selection/route/Q-signature/referenced-probes 快照。complete 在同一锁协议内重验当前路线和全部 claim 快照。旧 RUNNING compute 缺任一 freshness snapshot 时 fail closed，需走显式 reopen/reset。

数值唯一来源为 .mathmod/claim_registry.json 和结果文件。上游问题变更时，必须按 question DAG 失效所有 downstream dependents；禁止只改 Q1 而继续沿用依赖 Q1 的 Q2/Q3 旧数字。

S4 RESULT GATE

把题面约束翻译成 .mathmod/result_contract.yaml，运行 check_result_files.py。 每个提交结果至少有存在性、结构、数值卫生和题目业务约束；官方模板须原位填写并结构 diff。空 rules 或结果文件未被规则覆盖直接失败。

S5 EVIDENCE GATE

冻结产物指纹，逐问登记关键主张。每问至少一个 result 类主张；关键数字覆盖目标 ≥95%。运行 check_evidence.py 核对论文、结果、运行记录和冻结哈希。表格/推导也必须登记并在 S7 审查。

S6 WRITE

按模板生成论文，摘要最后写。每问结构：题意→假设/符号→模型→求解→结果→验证→回扣。图表必须由在册脚本/数据生成，图后解释其支持的论点。写作只引用已存在的证据，不得生成结果。

S7 ATTACK/REPAIR

第一层做全覆盖扫描：question × {intent, assumptions, model, solve, results, validation, answer}。

第二层做风险驱动深挖：ATTACKER 从当前 selected method 的 recipe 获取 validation/audit/failure/stop 条目，并加载对应专项审计。例如预测题展开 split/leakage/baseline/residual/uncertainty；优化题展开 constraint/status/gap/rounding/objective recomputation。矩阵是最低覆盖保证，不是为了填表而审查。

非 PASS 必须含位置、病症、最小修复和严重度。修复优先回到根因阶段；mathmod_orchestrator.py repair-plan 根据问题维度和 DAG 生成重跑范围。

S8 FORMAT GATE

用户可见论文最终件固定为 release/paper.docx 与 release/paper.pdf，Markdown 只允许放在 .mathmod/work/ 内部且发布后清理。Word 必须无批注、追踪修订和插入/删除痕迹；可见目录禁止 最终版/修改版/v2/final_final 等版本命名。

运行 check_format.py。赛事 MUST 必须符合 references/sources/rule-policy.yaml；Skill 自己的固定命名等应标为 IMPLEMENTATION_CONSTRAINT，不得冒充官方规则。用多模态逐页检查公式、图表、重叠、截断、空白和模板结构。

S9 INDEPENDENT ACCEPTANCE & RELEASE

全新 ACCEPTOR 只读题面、官方模板和最终磁盘文件，从原文独立实现检查。 .mathmod/independent_acceptance.json 声明不同的 producer_id/validator_id、当前 registry/contract 与 validator path/hash。S9 的预期 (constraint_id, artifact_path) 集由 canonical acceptance mapping 推导；未知或 malformed rule fail closed。S9 实际以 JSON stdin/stdout 合约在单独 subprocess 运行声明的 Python validator，请求携带 current registry、contract、expected pairs 与 artifact context；subprocess 输出只是补充 witness。pipeline-owned check_result_files.py 还会独立执行每条 mapped canonical rule，只有两侧均通过才形成 S9 PASS。预写/echo checks 不作为 verdict。validator 与 producer 的路径/哈希差异只表示 integrity separation，不宣称 OS sandbox 或 fresh isolated session。

最终 Word/PDF、结果、代码、运行清单、AI 使用说明和支撑 ZIP 缺一不可。若 execution state 存在，finalize 要求 canonical plan 全部 task DONE，验证前记录 state hash，并在 release manifest 提交前重验；这是 quiescent-tree consistency，不是全文件系统事务。每次 audit/finalize 使用同一 generation/epoch 绑定 state/receipts/report，并用仅驻留本次 validator 进程的 input hash registry 记录首读输入（明确包含 project.yaml），发布前逐项重验。全绿 finalize 先提交 VALIDATED + release_ready=false metadata，再原子写绑定本代哈希的 release_manifest.json；发布段出现任意 BaseException 会先撤销该 manifest。该 manifest 是唯一发布凭据，status 只在其完整校验后派生 RELEASE_READY。orchestrator/protocol 无此权限。

Agent 角色边界

• ANALYST：S0-S2，负责语义、数据、问题 DAG、歧义/假设、problem signature、路线；不写论文结果。
• PROBER：S1/S2 间做低成本诊断实验；只提供诊断证据，可请求 reopen S1/S2；不得产出最终数字。
• COMPUTER：S3-S4，写/跑正式代码与生成结果；不得签最终验收。
• WRITER：S5-S6，只引用登记证据；无证据写“需补计算”。
• ATTACKER：S7，隔离视角；先全维扫描，再按风险动态展开专项攻击。
• ACCEPTOR：S9，从题面重建验收器，不读求解器校验代码。
• FINAL JUDGE：只读题面、最终论文、登记簿、提交本体和独立回执。

角色提示词见 roles/。隔离角色优先用 subagent；大规模多维攻击仅在用户明确要求工作流时使用。

Agent Runtime Protocol

协议详见 references/agent-protocol.md。Agent 不应“看到 plan 后自己随意执行”，而应使用：

next → claim → task packet → work → complete/fail

.mathmod/execution_state.json 维护 PENDING / READY / RUNNING / DONE / FAILED / BLOCKED。READY 由 task DAG 的依赖自动推导；只有 claim worker 能 complete/fail。task 的显式 question/role/action/stage 及 ID 必须符合 canonical grammar。init --force 受 protocol lock 保护，任一 RUNNING lease 存在时拒绝，且不作为 repair/reset 手段。

claim 返回 task packet：

• role_prompt：当前角色边界；
• read_scope：当前 task 优先读取范围；
• knowledge_bundle：按 QID/role/action 裁剪的 method + recipe + failure + audit；
• completion_contract：必须提交的 handoff；
• hard_boundaries：不得伪造 validator / probe 最终化等。

当前 execution plan/packet 不声明通用 capability/provider 字段，也不产生 capability resolution/history/event。角色提示与 recipe 投影直接由规范 role/action 选择。只有真实出现两个以上可互换 provider 且产生运行故障模式时，才进入后续 provider routing 设计；当前未接入 external adapter 或 My-MathModeling-skills runtime。

PROBER handoff 若请求 reopen，protocol 调用 dependency-aware invalidation 并把受影响 task 重置；这才算真实重开。所有 task DONE 后仍必须单独运行 validation state machine。

问题依赖与失效传播

question_graph.yaml 是逐问依赖的单一事实源。上游语义、假设、模型或正式结果变化时：

1. 调用 orchestrator invalidate，计算受影响问题的 transitive closure。
2. 把 durable validity/strategy epoch 写入现有 .mathmod/state.json，并写 invalidation intent 与 repair plan。
3. 运行 execution_protocol.py apply-invalidation，只把各问 restart_stage 覆盖的 task 重新置为待执行；下游正式结果、claims、论文段落与最终验收均视为 stale。
4. validator 的旧回执不会被 orchestrator/protocol 篡改；真正重新变绿仍需执行对应 S0-S9 gate。

模型/知识路由

先读取 problem_signature.yaml，再由 scripts/knowledge_router.py 使用：

• 路由策略：references/knowledge/retrieval-router.yaml
• 方法目录：references/knowledge/method-library.yaml
• recipe 索引：references/knowledge/recipe-index.yaml
• 优化 recipe：references/recipes/optimization.yaml
• 预测 recipe：references/recipes/prediction.yaml
• 评价 recipe：references/recipes/evaluation.yaml
• 机理/仿真 recipe：references/recipes/mechanism-simulation.yaml
• 优化审计：references/model-audit/optimization.md
• 预测审计：references/model-audit/prediction.md
• 评价审计：references/model-audit/evaluation.md
• 机理设计：references/knowledge/mechanism.md
• 高风险失败：references/knowledge/failure-patterns.md

任何候选模型必须同时写：适用条件、反适用条件、所需数据、基线、验证、失败退路。专项 audit 可在设计期作为 checklist 加载，但不能反向强迫采用某模型。Recipe 命中也不是证据；若题意/数据不匹配，Agent 必须拒绝 recipe 并登记 knowledge gap。

修复纪律

1. 先修题意/假设/生成器/契约/验收器根因，再修叙述。
2. P0 数字、可行性、泄漏或题意错误阻断所有档位判断。
3. 修复原位写入固定 Word/工作文件；禁止可见 CHANGELOG、版本副本和 paper_v2_final_final 文件堆。
4. 必要审计事件只追加到 .mathmod/events.jsonl，不进入 Word/PDF，不向评审暴露修改历史。
5. 修复后按 question DAG + stage dependency 只重跑受影响闭包；哈希变化必须重新冻结。
6. 不可完成项进入 .mathmod/deferred.json；存在开放 P0/P1 不得发布。

知识来源与规则强度

references/sources/manifest.yaml 记录来源、哈希、权威等级、定位和许可状态。 references/sources/rule-policy.yaml 负责把 authority 绑定到 MUST / TECHNICAL_CONSTRAINT / IMPLEMENTATION_CONSTRAINT / SHOULD / HEURISTIC / MAY。

原则：

• A/B 只有在当前、已核验且原文明确支持时才允许形成赛事 MUST。
• C/D 可形成技术/实现约束，但不能冒充赛事规则。
• E/F 只能作为 SHOULD/HEURISTIC；可触发审查问题，但不能单独给出“官方违规”结论。
• 来源冲突或版本不明进入 ambiguity_registry；禁止 Agent 静默选一个。

用户提供的扫描讲义、自查表和模板属于本地第三方资料，内容可提炼为启发式知识，但未经官方来源核验不得作为 MUST。原始二进制不随 Skill 复制；通过本地路径和哈希引用。

自检

python3 scripts/check_skill.py --with-tests
python3 tests/run_all.py

若自检、Agent protocol 测试、recipe router 测试或反绕过夹具不绿，禁止宣称 Skill 可用于终稿发布。