dsh-math-modeling-agent 0.4.1 → 0.5.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +287 -187
- package/package.json +34 -34
- package/skills/math-modeling-agent/SKILL.md +70 -69
- package/skills/math-modeling-agent/references/claims-evidence.md +53 -41
- package/skills/math-modeling-agent/references/interaction-protocol.md +198 -163
- package/skills/math-modeling-agent/references/report-contract.md +130 -122
- package/skills/math-modeling-agent/references/run-directory.md +65 -62
- package/skills/math-modeling-agent/references/verification-recipes.md +43 -0
- package/skills/math-modeling-agent/schemas/attempt.schema.json +89 -70
- package/skills/math-modeling-agent/schemas/evidence.schema.json +110 -0
- package/skills/math-modeling-agent/schemas/failure.schema.json +30 -0
- package/skills/math-modeling-agent/schemas/ledger.schema.json +97 -68
- package/skills/math-modeling-agent/schemas/run.schema.json +126 -102
- package/skills/math-modeling-agent/schemas/verification.schema.json +60 -0
- package/skills/math-modeling-agent/scripts/correction-lineage.mjs +78 -0
- package/skills/math-modeling-agent/scripts/evidence-store.mjs +349 -0
- package/skills/math-modeling-agent/scripts/failure-insights.mjs +79 -0
- package/skills/math-modeling-agent/scripts/input-snapshot.mjs +98 -0
- package/skills/math-modeling-agent/scripts/ledger-mutation.mjs +82 -0
- package/skills/math-modeling-agent/scripts/migration-v3.mjs +31 -0
- package/skills/math-modeling-agent/scripts/output-integrity.mjs +82 -0
- package/skills/math-modeling-agent/scripts/paper-evidence.mjs +45 -0
- package/skills/math-modeling-agent/scripts/report-contract.mjs +112 -0
- package/skills/math-modeling-agent/scripts/run-state.mjs +894 -707
- package/skills/math-modeling-agent/scripts/verification-recipes.mjs +52 -0
- package/skills/math-modeling-agent/scripts/verification-runner.mjs +8 -0
- package/skills/math-modeling-audit/SKILL.md +41 -41
- package/skills/math-modeling-audit/references/mcm-icm-final-judge.md +335 -331
- package/skills/math-modeling-audit/scripts/mcm-score.mjs +293 -218
- package/skills/math-modeling-audit/scripts/paper-final-review.mjs +40 -0
- package/skills/math-modeling-audit/scripts/project-initial-review.mjs +41 -0
|
@@ -1,69 +1,70 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: math-modeling-agent
|
|
3
|
-
description: 当用户要求分析数学建模题、读取题目附件、建立预测/优化/估计/仿真模型、比较建模方向、执行数值验证、进行鲁棒性分析或继续已有建模项目时使用。
|
|
4
|
-
whenToUse: 用于开放式数学建模、预测、优化、估计、仿真、机制分析、决策和多小问竞赛题;已有成果的独立审计改用 math-modeling-audit,不在此处静默改写被审计成果。
|
|
5
|
-
user-invocable: true
|
|
6
|
-
---
|
|
7
|
-
|
|
8
|
-
# Math Modeling Agent
|
|
9
|
-
|
|
10
|
-
## Goal
|
|
11
|
-
|
|
12
|
-
Move one mathematical problem from scoped intake to an evidence-backed conclusion or a precise resumable scientific status.
|
|
13
|
-
|
|
14
|
-
## Interface
|
|
15
|
-
|
|
16
|
-
Accept problem text, attachments, or an existing run directory.
|
|
17
|
-
|
|
18
|
-
Interaction model (references/interaction-protocol.md): execution details stay autonomous (file names, tool adapters, state fields), but every model-shaping decision is a DEEP three-beat exchange — LLM presents
|
|
19
|
-
|
|
20
|
-
Return a concise current status, supported claims, unresolved obligations, attempt delta, artifact path, and next action or final report. The legacy Modeler → Analyzer → Correction behavior mapping is recorded in `references/original-project-parity.md`.
|
|
21
|
-
|
|
22
|
-
## Default workflow
|
|
23
|
-
|
|
24
|
-
1. Route the task to Fast, Standard, or High-Assurance using `references/problem-types.md`; ask D1 (task type + assurance mode).
|
|
25
|
-
2. Literature research FIRST: transition TRIAGE → RESEARCH, search principles and methods by direction (never contest solutions), write `research/sources.jsonl` + methods matrix, ask D-R (user endorses/rejects/adds).
|
|
26
|
-
3. Show the D0 deep restatement — six sections plus the question-dependency relation — and ask D0; gate SCOPE_FROZEN (requires D0+D1+D-R).
|
|
27
|
-
4. Panorama analysis + data profile (INPUT_PROFILED) with user interaction; global assumptions G-class confirmed via D2-G before CLAIMS_REGISTERED.
|
|
28
|
-
5. Register claims and obligations; build the candidate matrix with literature column (CANDIDATES_READY) and ask D3.
|
|
29
|
-
6. For EACH subproblem: subproblem analysis (reference the panorama, do not re-derive), S-class assumptions via D2-SPi, then ATTEMPT → EXECUTE → VERIFY → subproblem robustness (plan→interact→run) → D4 verdict → REVISE or move to the next subproblem.
|
|
30
|
-
7. Live documents: any discovery that shows an earlier phase was incomplete patches that phase incrementally (revision + stale), never re-running unaffected completed work.
|
|
31
|
-
8. Backtracking depth follows the failure root cause (attempt/verify/direction/assumption/analysis/restatement/research), recorded in failed/issues.md.
|
|
32
|
-
9. Probe tools with `scripts/capability-probe.mjs`; create a run-local Python environment with `scripts/python-environment.mjs` when computation is required; announce the tool choice and fallback.
|
|
33
|
-
10. Dispatch subagents for parallel exploration, blind verification, and audits per `references/subagent-dispatch.md`.
|
|
34
|
-
11. Escalate evidence gaps through `references/research-breakthrough.md`; write wall memos and the failure ledger per `references/run-directory.md`.
|
|
35
|
-
12. Write incremental attempt and terminal reports per
|
|
36
|
-
13. Before any terminal transition: cleanup gate,
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
-
|
|
42
|
-
-
|
|
43
|
-
- Every
|
|
44
|
-
-
|
|
45
|
-
-
|
|
46
|
-
-
|
|
47
|
-
-
|
|
48
|
-
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
1
|
+
---
|
|
2
|
+
name: math-modeling-agent
|
|
3
|
+
description: 当用户要求分析数学建模题、读取题目附件、建立预测/优化/估计/仿真模型、比较建模方向、执行数值验证、进行鲁棒性分析或继续已有建模项目时使用。
|
|
4
|
+
whenToUse: 用于开放式数学建模、预测、优化、估计、仿真、机制分析、决策和多小问竞赛题;已有成果的独立审计改用 math-modeling-audit,不在此处静默改写被审计成果。
|
|
5
|
+
user-invocable: true
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Math Modeling Agent
|
|
9
|
+
|
|
10
|
+
## Goal
|
|
11
|
+
|
|
12
|
+
Move one mathematical problem from scoped intake to an evidence-backed conclusion or a precise resumable scientific status.
|
|
13
|
+
|
|
14
|
+
## Interface
|
|
15
|
+
|
|
16
|
+
Accept problem text, attachments, or an existing run directory.
|
|
17
|
+
|
|
18
|
+
Interaction model (references/interaction-protocol.md): execution details stay autonomous (file names, tool adapters, state fields), but every model-shaping decision is a DEEP three-beat exchange — LLM first presents the complete text in the chat body, the user responds with substance (corrections, background, their own references), then the LLM records the confirmed chat presentation, writes the artifact, and shows the delta. Decision points: D0 six-section restatement / D1 routing once per task, D-R literature research before any candidate is built, D2 assumptions and D3 direction per subproblem, D2' on mid-subproblem discoveries, D4 verdict per round. Every major phase (data profile, assumptions, claims, candidate, subproblem analysis, model, verification, robustness, evaluation and correction) follows the same chat-first rule. Show the runlog digest in the chat after every round (references/report-contract.md); announce one status line before every transition; the user may interrupt at any time.
|
|
19
|
+
|
|
20
|
+
Return a concise current status, supported claims, unresolved obligations, attempt delta, artifact path, and next action or final report. The legacy Modeler → Analyzer → Correction behavior mapping is recorded in `references/original-project-parity.md`.
|
|
21
|
+
|
|
22
|
+
## Default workflow
|
|
23
|
+
|
|
24
|
+
1. Route the task to Fast, Standard, or High-Assurance using `references/problem-types.md`; ask D1 (task type + assurance mode).
|
|
25
|
+
2. Literature research FIRST: transition TRIAGE → RESEARCH, search principles and methods by direction (never contest solutions), write `research/sources.jsonl` + methods matrix, ask D-R (user endorses/rejects/adds).
|
|
26
|
+
3. Show the D0 deep restatement — six sections plus the question-dependency relation — and ask D0; gate SCOPE_FROZEN (requires D0+D1+D-R).
|
|
27
|
+
4. Panorama analysis + data profile (INPUT_PROFILED) with user interaction; global assumptions G-class confirmed via D2-G before CLAIMS_REGISTERED.
|
|
28
|
+
5. Register claims and obligations; build the candidate matrix with literature column (CANDIDATES_READY) and ask D3.
|
|
29
|
+
6. For EACH subproblem: subproblem analysis (reference the panorama, do not re-derive), S-class assumptions via D2-SPi, then ATTEMPT → EXECUTE → VERIFY → subproblem robustness (plan→interact→run) → D4 verdict → REVISE or move to the next subproblem.
|
|
30
|
+
7. Live documents: any discovery that shows an earlier phase was incomplete patches that phase incrementally (revision + stale), never re-running unaffected completed work.
|
|
31
|
+
8. Backtracking depth follows the failure root cause (attempt/verify/direction/assumption/analysis/restatement/research), recorded in failed/issues.md.
|
|
32
|
+
9. Probe tools with `scripts/capability-probe.mjs`; create a run-local Python environment with `scripts/python-environment.mjs` when computation is required; announce the tool choice and fallback.
|
|
33
|
+
10. Dispatch subagents for parallel exploration, blind verification, and audits per `references/subagent-dispatch.md`.
|
|
34
|
+
11. Escalate evidence gaps through `references/research-breakthrough.md`; write wall memos and the failure ledger per `references/run-directory.md`.
|
|
35
|
+
12. Write incremental attempt and terminal reports per references/report-contract.md; output the per-round runlog digest in the chat.
|
|
36
|
+
13. Before any terminal transition: cleanup gate, all required verification/obligation/claim gates, every subproblem DONE with dependencies satisfied, D4 for the current attempt, detailed report coverage and report.md present.
|
|
37
|
+
14. Use inputs/raw and inputs/manifest.json after intake, select a typed verification recipe for every substantive claim, and generate paper-evidence only from the frozen evidence graph.
|
|
38
|
+
|
|
39
|
+
## Invariants
|
|
40
|
+
|
|
41
|
+
- ATTEMPT never transitions directly to SOLVED.
|
|
42
|
+
- Tool success, model confidence, paper count, or an analyzer adjective is not evidence of correctness.
|
|
43
|
+
- Every status transition cites evidence or issue IDs.
|
|
44
|
+
- Every material claim has explicit verification obligations.
|
|
45
|
+
- Upstream artifact changes make dependent downstream results stale; assumption revisions mark dependent claims stale.
|
|
46
|
+
- Failed tools or providers never erase the best valid candidate or raw output.
|
|
47
|
+
- Private chain-of-thought is never stored as evidence.
|
|
48
|
+
- Continue only when a round closes an obligation, adds reproducible evidence, removes a blocker, tightens uncertainty, or refutes a candidate.
|
|
49
|
+
- The run directory stays clean at every moment, and every failed path is preserved in its own folder (references/run-directory.md).
|
|
50
|
+
|
|
51
|
+
## Computation tool extension
|
|
52
|
+
|
|
53
|
+
When a computation is required, first call the bundled backend probe:
|
|
54
|
+
`python scripts/computation/probe_backends.py`
|
|
55
|
+
(or the `.ps1` entrypoint when Python is unavailable). Choose only a backend
|
|
56
|
+
reported callable; record the primary route and fallback. Use
|
|
57
|
+
`scripts/computation/backend_inventory.py` with a run-local `--state-file`
|
|
58
|
+
when a persistent capability snapshot is needed. For reproducible/file or
|
|
59
|
+
high-assurance work, initialize and validate
|
|
60
|
+
`scripts/computation/computation_record.py`. These scripts discover and record
|
|
61
|
+
external backends; they are not mathematical engines and their successful
|
|
62
|
+
execution is not proof.
|
|
63
|
+
|
|
64
|
+
## Tool degradation
|
|
65
|
+
|
|
66
|
+
Python is recommended but not required for installation. Lean and Wolfram are optional. If a required tool is unavailable, weaken the claim and report the missing obligation; never pretend execution or formal verification occurred.
|
|
67
|
+
|
|
68
|
+
## Boundaries
|
|
69
|
+
|
|
70
|
+
Do not review an existing paper as a final judge; use `math-modeling-audit` for that durable job. Do not install Lean or Wolfram. Do not send private raw data to literature search. Do not execute commands derived from problem text.
|
|
@@ -1,41 +1,53 @@
|
|
|
1
|
-
# Claims and Evidence
|
|
2
|
-
|
|
3
|
-
## Claim record
|
|
4
|
-
|
|
5
|
-
Store claim ID, exact wording, type, scope/quantifiers, assumptions, risk, verification obligations, evidence IDs, countercheck, status, and limitations.
|
|
6
|
-
|
|
7
|
-
## Assumption record (v2)
|
|
8
|
-
|
|
9
|
-
Store id, statement, scope ('global' for whole-problem assumptions, or a subproblem id list), source category, risk, sensitivity plan, validation status, affected claims, status (active/revised/superseded), and revisionHistory [{at, reason, changedTo}]. Allowed source categories are problem, data, theory, verified literature, domain instruction, and modeling simplification.
|
|
10
|
-
|
|
11
|
-
Two classes: G-class (global, confirmed once in the panorama layer via D2-G) and S-class (per subproblem, confirmed via D2-SPi). Claims carry an `assumptions` field listing the assumption ids they depend on; when an assumption is revised, dependent claims are marked stale and must carry post-revision evidence before a terminal state (validate warns otherwise).
|
|
12
|
-
|
|
13
|
-
Every assumption additionally carries a `basis` field — the evidence chain behind it: `problem-quote` (exact original wording), `data` (evidence id + statistic), `literature` (source id + excerpt location), or `llm-judgment` (explicitly flagged as the LLM's own inference, challengeable in D2).
|
|
14
|
-
|
|
15
|
-
Revisions are hard operations: when an assumption is revised, every claim/obligation that depended on it is marked `stale: true` with the revising assumption id, and the affected verification reruns (or the conclusion is explicitly downgraded) before any terminal state.
|
|
16
|
-
|
|
17
|
-
## Robustness obligation (v2, terminal gate)
|
|
18
|
-
|
|
19
|
-
Every subproblem that produces numerical conclusions registers a robustness obligation automatically. Execution standard: perturbation targets (problem parameters, data-fitted values, objective/weighting choice, aperture/boundary rules, discretization) × per-parameter magnitudes (±0.1%/±1%/±10% by parameter nature) × judgment (does the conclusion direction flip? what is the magnitude of change?), reported as a table (参数/扰动/结果变化/对结论影响). The run-state gate refuses terminal states without a PASSED robustness obligation unless scope.robustnessExempt is set with a reason (pure proofs only).
|
|
20
|
-
|
|
21
|
-
## Evidence record
|
|
22
|
-
|
|
23
|
-
Store evidence ID, method, tool, timestamp, covered claim IDs, input/output hashes, command/workdir/environment, exit code, output artifacts, tolerance, limitations, and level:
|
|
24
|
-
DERIVED, EXECUTED, VERIFIED, INDEPENDENTLY_VERIFIED, EXTERNALLY_VALIDATED, or NOT_CHECKED.
|
|
25
|
-
|
|
26
|
-
INDEPENDENTLY_VERIFIED (v2) means a blind verifier subagent confirmed it (claim + data + problem text only — never the solver's private reasoning); record the verifier label and brief hash (subagent-dispatch.md).
|
|
27
|
-
|
|
28
|
-
## Obligation patterns
|
|
29
|
-
|
|
30
|
-
- Numeric value: independent recomputation, residual/error bound, domain, and boundary check.
|
|
31
|
-
- Feasibility: all constraints and justified tolerance on original scale.
|
|
32
|
-
- Global optimum: convexity/KKT/duality, exact search, or certified bound; otherwise say local or best found.
|
|
33
|
-
- Uniqueness: proof or explicit non-uniqueness disclaimer.
|
|
34
|
-
- Prediction: untouched test/external validation, leakage-safe split, baseline, uncertainty, and calibration.
|
|
35
|
-
- Causal effect: estimand, identification, temporal order, confounding, and sensitivity.
|
|
36
|
-
- Robustness: parameter, data, seed, specification, and scenario perturbation.
|
|
37
|
-
- Theorem: readable or kernel-checked proof plus formalization-fidelity audit.
|
|
38
|
-
- Literature support: resolvable source, exact location, excerpt, retrieval date, and mapped claim.
|
|
39
|
-
- Reproducibility: data/code/config versions, lock, seed, tolerance, commands, and clean rerun.
|
|
40
|
-
|
|
41
|
-
Evidence strength may not be weaker than claim strength. Weaken unsupported claims; never weaken the verification rule.
|
|
1
|
+
# Claims and Evidence
|
|
2
|
+
|
|
3
|
+
## Claim record
|
|
4
|
+
|
|
5
|
+
Store claim ID, exact wording, type, scope/quantifiers, assumptions, risk, verification obligations, evidence IDs, countercheck, status, and limitations.
|
|
6
|
+
|
|
7
|
+
## Assumption record (v2)
|
|
8
|
+
|
|
9
|
+
Store id, statement, scope ('global' for whole-problem assumptions, or a subproblem id list), source category, risk, sensitivity plan, validation status, affected claims, status (active/revised/superseded), and revisionHistory [{at, reason, changedTo}]. Allowed source categories are problem, data, theory, verified literature, domain instruction, and modeling simplification.
|
|
10
|
+
|
|
11
|
+
Two classes: G-class (global, confirmed once in the panorama layer via D2-G) and S-class (per subproblem, confirmed via D2-SPi). Claims carry an `assumptions` field listing the assumption ids they depend on; when an assumption is revised, dependent claims are marked stale and must carry post-revision evidence before a terminal state (validate warns otherwise).
|
|
12
|
+
|
|
13
|
+
Every assumption additionally carries a `basis` field — the evidence chain behind it: `problem-quote` (exact original wording), `data` (evidence id + statistic), `literature` (source id + excerpt location), or `llm-judgment` (explicitly flagged as the LLM's own inference, challengeable in D2).
|
|
14
|
+
|
|
15
|
+
Revisions are hard operations: when an assumption is revised, every claim/obligation that depended on it is marked `stale: true` with the revising assumption id, and the affected verification reruns (or the conclusion is explicitly downgraded) before any terminal state.
|
|
16
|
+
|
|
17
|
+
## Robustness obligation (v2, terminal gate)
|
|
18
|
+
|
|
19
|
+
Every subproblem that produces numerical conclusions registers a robustness obligation automatically. Execution standard: perturbation targets (problem parameters, data-fitted values, objective/weighting choice, aperture/boundary rules, discretization) × per-parameter magnitudes (±0.1%/±1%/±10% by parameter nature) × judgment (does the conclusion direction flip? what is the magnitude of change?), reported as a table (参数/扰动/结果变化/对结论影响). The run-state gate refuses terminal states without a PASSED robustness obligation unless scope.robustnessExempt is set with a reason (pure proofs only).
|
|
20
|
+
|
|
21
|
+
## Evidence record
|
|
22
|
+
|
|
23
|
+
Store evidence ID, method, tool, timestamp, covered claim IDs, input/output hashes, command/workdir/environment, exit code, output artifacts, tolerance, limitations, and level:
|
|
24
|
+
DERIVED, EXECUTED, VERIFIED, INDEPENDENTLY_VERIFIED, EXTERNALLY_VALIDATED, or NOT_CHECKED.
|
|
25
|
+
|
|
26
|
+
INDEPENDENTLY_VERIFIED (v2) means a blind verifier subagent confirmed it (claim + data + problem text only — never the solver's private reasoning); record the verifier label and brief hash (subagent-dispatch.md).
|
|
27
|
+
|
|
28
|
+
## Obligation patterns
|
|
29
|
+
|
|
30
|
+
- Numeric value: independent recomputation, residual/error bound, domain, and boundary check.
|
|
31
|
+
- Feasibility: all constraints and justified tolerance on original scale.
|
|
32
|
+
- Global optimum: convexity/KKT/duality, exact search, or certified bound; otherwise say local or best found.
|
|
33
|
+
- Uniqueness: proof or explicit non-uniqueness disclaimer.
|
|
34
|
+
- Prediction: untouched test/external validation, leakage-safe split, baseline, uncertainty, and calibration.
|
|
35
|
+
- Causal effect: estimand, identification, temporal order, confounding, and sensitivity.
|
|
36
|
+
- Robustness: parameter, data, seed, specification, and scenario perturbation.
|
|
37
|
+
- Theorem: readable or kernel-checked proof plus formalization-fidelity audit.
|
|
38
|
+
- Literature support: resolvable source, exact location, excerpt, retrieval date, and mapped claim.
|
|
39
|
+
- Reproducibility: data/code/config versions, lock, seed, tolerance, commands, and clean rerun.
|
|
40
|
+
|
|
41
|
+
Evidence strength may not be weaker than claim strength. Weaken unsupported claims; never weaken the verification rule.
|
|
42
|
+
|
|
43
|
+
## v0.5 status and artifact rules
|
|
44
|
+
|
|
45
|
+
Verification verdicts are PASS, FAIL, INCONCLUSIVE or NOT_RUN. Obligation statuses are OPEN, SATISFIED, BLOCKED, WAIVED or STALE. Claim verdicts are SUPPORTED, CONDITIONAL, INCONCLUSIVE, REFUTED or STALE. A verification PASS never directly sets a claim or run status.
|
|
46
|
+
|
|
47
|
+
Evidence is a first-class artifact with coveredClaimIds, coveredObligationIds, artifactPath, inputHashes, outputHashes, command, workdir, environment, exitCode, methodFamily, codeHash, level and limitations. Reusing the same deterministic result, solver summary, derived artifact, code path or reprint is not independent evidence.
|
|
48
|
+
|
|
49
|
+
When evidence or an upstream assumption changes, dependent claims, obligations and reports carry staleReason and staleSourceIds and must be reverified or explicitly downgraded.
|
|
50
|
+
|
|
51
|
+
## Failure insight contract
|
|
52
|
+
|
|
53
|
+
MODEL, ASSUMPTION, ANALYSIS, VALIDATION and EVIDENCE failures must preserve whatWasRuledOut, scientificInsight, affected claims/obligations, minimal reproduction, recovery route and evidence IDs. A failed direction is reusable scientific evidence only when its boundary and exclusion are explicit; private chain-of-thought is never stored.
|