This phase follows and . If H2 for CUMCM 2026 has not been explicitly approved, stop and return to ; do not select a core model on your own.

As needed, read the “Question-Type Error-Prevention Quick Reference,” “Code Implementation and Results,” “Common Coding Errors,” and “Charts and Visualization” sections of .

Responsible for: runnable source code, environment manifest, experiment outputs, result records, constraint checks, baseline, sensitivity analysis, and data-driven figures. Not responsible for flowcharts, architecture diagrams, or the paper body.

At least create:

code/
├── run_all.py
├── problem1.py
├── ...
├── utils.py
├── requirements.txt            # 或 environment.yml
└── outputs/
    ├── preprocessing_summary.json
    ├── model_parameters.json
    ├── constraint_check.json
    ├── sensitivity.csv
    ├── figure_data/
    └── logs/
results/
├── final_results.json
└── constraint_check.json
reports/RESULTS_REPORT.md
figures/*.pdf

Remove inapplicable intermediate files as appropriate for the actual problem, but , the environment manifest, , constraint/validity check records, and are required outputs in CUMCM mode.

should start from the raw inputs and execute preprocessing, each subproblem, baseline, validation, sensitivity analysis, result tables, and figure generation in dependency order. It must not rely on hidden IDE state, manually modified intermediate files, or undocumented interactive operations.

The environment manifest must list only dependencies actually used and record the Python version. Fix seeds for stochastic processes; when stability conclusions are needed, use multiple independent runs and record the distributions. Resolve relative paths explicitly from the project root or script location so that the workflow does not run only on the author’s machine.

For each subproblem, proceed in this order: read data → implement → small-sample test → main run → independent validation → save results. If the implementation differs from the H2-approved approach, first explain the reasons and impact in the report, and, in CUMCM mode, request team confirmation of substantive changes.

For optimization problems, construct a feasible solution before optimization; for prediction problems, use correct training/validation boundaries; for evaluation problems, record metric direction, normalization, and the source of weights; for simulation problems, check units, boundary conditions, and convergence.

For each core conclusion, implement a task-appropriate simple baseline or small-scale exact reference solution, for example:

Comparisons must use the same data splits, constraints, and evaluation criteria. If a baseline is not applicable, document the specific reason; do not merely state that the main model is more advanced.

A solver’s does not mean that the model solution is valid. Use validation logic independent of the objective solver to plug back and check each item:

Write constraint values, permitted bounds, slack, and pass status to . The validation logic itself must not reuse the same potentially erroneous expression in a way that compromises independence. Failed constraints must prevent results from being marked final.

serves as the single source of truth for numerical values in the paper and records their definitions, units, and precision; chart data is saved to . documents the runtime environment, data processing, results for each question, baseline, validation, sensitivity, consistency with the modeling reports, and the complete execution command.

Generate vector PDF figures in as needed to support the actual analysis. For prediction, use actual-vs-predicted comparisons and error distributions; for optimization, use convergence, resource utilization, and solution comparisons; for evaluation, use rankings, heatmaps, and sensitivity plots. Every figure must be generated from saved data and referenced in .

Do not place large titles inside figures; text, axes, and legends must use the same language as the paper; ensure that figures remain distinguishable in grayscale. Do not generate flowcharts, architecture diagrams, or charts merely to increase the number of figures.

In CUMCM 2026 mode, after completing a reproducible run and independent validation, write the following to :

STATUS: WAITING_FOR_HUMAN_RESULT_REVIEW

Provide the competition team with the minimum sufficient materials for review: the complete execution command, key results and units, baseline comparison, constraint checks, edge cases, sensitivity results, and core figures. Only after team members have explicitly rerun or verified the results and explained any modifications may be recorded. The Agent must not check review items on the team’s behalf; if H3 is not approved, the results must not be handed to the paper stage as final conclusions.

In CUMCM 2026 mode, append an entry to for each significant coding task, recording the tool name and version/model, workflow stage, purpose, main prompting approach, AI output, adopted/not adopted content, human modifications, and verification. All code and analysis other than language polishing must undergo a recorded human review; unknown information must not be guessed.