Cumcm Workflow

Modeling Workbench

Spend reasoning on the problem, mathematics, experiments and explanation. Tools maintain execution records, hashes, snapshots and stage state. Do not create extra checklists or repeatedly edit contracts to silence warnings.

Competition and task routing

For a new competition, read competition adaptation to identify the current official requirements and the supported automation boundary. Competition names do not determine methods, page limits or evidence standards. Keep the existing stages, two knobs and three human stops.

Read additional guidance only when the active work needs it:

For paper initialization, pass the actual --competition and --language zh|en to init_latex_paper.py; omitted options retain CUMCM/Chinese behavior. The shared LaTeX/PDF compile, review and source-package chain works across competition names. Generic scaffolds are not official templates: current-rule compliance, page QA and the three human stops still apply. DOCX export is not implemented.

Start or resume

1. Read the project's .cumcm/state.json and the incoming handoff, if present. Resume exact 0.6.0 projects; older schemas are unsupported.
2. For a new project, use intake and init_project.py with the supplied official files.
3. Read only the active stage guide below. Consult a schema only when the guide and command help leave a specific field unresolved; do not load the checker to learn the workflow.
4. Define S as the absolute path to this Skill's scripts directory. All examples use python3 "$S/<command>.py"; the contest workspace does not contain these scripts.
5. After interruption, check pending human decisions before continuing. Existing downstream files do not establish approval. Never infer approval from a quota reset, a new task, or “continue”.

Setup and progress diagnostics

On first setup or an environment change, run python3 "$S/doctor.py"; on resumption or a progress question, run python3 "$S/project_status.py" --project <p>. Both print reports without changing project state. Summarize what is usable, what blocks the next action, and the next step; continue authorized work instead of adding a confirmation point. Missing paper tools do not block modeling. A ready preflight is not approval: read the separately reported checkpoint availability. Use diagnostics for probe depth, JSON output, optional model dependencies and exit codes. Do not run diagnostics on every reply or reinstall an already prepared environment.

Three human stops

Stop the dependent work after presenting the material. Model self-review is useful judgement, never human acceptance. A reply before the material was shown does not approve it. If a reviewed claim or model changes, show the revision and obtain a new decision; do not relabel the old acceptance.

After the user accepts all the presented current material, one command fills the existing checkpoint, records its snapshot and advances state:

bashCopy code
python3 "$S/record_decision.py" --project <p> --stage <stage> \
  --decision accepted --confirm-human --task-turn-ref <user-reply-ref> \
  --summary <what-the-user-accepted>

No manual timestamps, presented-ID lists, hashes or state edits. Other stages are technical completions: use the same command without --confirm-human, after their checks pass, referencing the current task. They do not require another user confirmation. Reopen with --decision revision_requested; downstream approvals become unusable. Decisions are honest conversation records, not cryptographic proof that a person answered.

Working and finalizing

• working permits incomplete model drafts and cheap exploratory runs. Failed exploration never blocks. Use preflight while drafting: pending review is visible but does not fail the command.
• enforce requires the three human stops in both modes. Official recording and paper entry also check the corresponding stop, so skipping a checker does not silently replace approval with self-review.
• finalizing requires complete current evidence, decisions, independent review and delivery binding. Switch with set_mode.py. Do not run full finalizing checks before exploratory model selection: formal assertions do not exist yet.

bashCopy code
python3 "$S/cumcm_check.py" --project <p> --stage <stage> --gate-mode preflight

Warnings remain visible; they are not a request to rewrite upstream evidence. An error requires repair; awaiting_review means present the material and wait. Passing does not prove mathematical correctness.

Stage guides

Build handoffs with build_handoff.py; read handoffs only at a crossing. computation-validation and validation-paper must cross into fresh tasks. Task refs are a paste guard, not proof of independence; same-model new-context review remains correlated. After a full review finds P0, the package builder defaults to targeted re-review of those findings.

Evidence without paperwork

• Preserve official files. record_run.py records real execution and freezes declared evidence; index_result.py reads values from outputs. Never type machine facts into contracts.
• Choose a model after cheap candidate evaluation; officially implement one backend. MATLAB preference breaks ties, not task suitability. No parity implementation unless requested.
• Runs are append-only. A rerun uses --rerun, never overwrites its parent. Only successful official descendants supersede. plan_redo.py scopes affected work; it does not waive checks.
• P0: wrong computation/data, task mismatch, scope beyond evidence, stale evidence, fabricated approval/review, or unusable delivery. P1: weaknesses within a supported and task-relevant scope. P2: optional improvements. Narrowing a claim cannot erase an unanswered requirement.
• Derive review priorities from the current task, not previous failure examples. Check task coverage, model assumptions, solution validity and claim scope using a few tests or independent arguments that could expose a plausible wrong answer. Choose applicable mathematical properties; do not require every problem to run the same tests. A repair must address the failure mechanism and affected conclusions, not only the failing example.
• Claims use supported_not_reproduced unless an isolated rerun and comparison establish reproduced. Label simulations and synthetic scenarios explicitly.
• Keep workflow IDs and evidence bookkeeping out of reader-facing prose. Compilation logs do not establish visual quality; inspect rendered pages.
• refresh_evidence.py --only delivery --package builds declared ZIPs with project-relative directories and refreshes their existing metadata. It never refreshes official sources. No-change refreshes do not rewrite files.

Use artifact contracts only for an unfamiliar artifact and evidence rules for unresolved evidence semantics. Do not read every reference at startup.