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,163 +1,198 @@
|
|
|
1
|
-
# Interaction Protocol (v2)
|
|
2
|
-
|
|
3
|
-
Three interaction layers. Execution details stay autonomous; every
|
|
4
|
-
model-shaping decision is visible and user-owned.
|
|
5
|
-
|
|
6
|
-
## Deep-exchange protocol (v2.6)
|
|
7
|
-
|
|
8
|
-
Every L1 decision point follows a three-beat exchange, never a one-way
|
|
9
|
-
"here is my conclusion, confirm it":
|
|
10
|
-
|
|
11
|
-
1. **LLM presents a complete analysis with its evidence chain.** Every claim
|
|
12
|
-
inside the analysis carries its basis: an exact quote from the problem
|
|
13
|
-
text, a data statistic, a literature source id, or an explicit
|
|
14
|
-
"LLM judgment" marker. A naked conclusion is not a presentation.
|
|
15
|
-
2. **The user responds with substance**: confirmation, correction, background
|
|
16
|
-
knowledge, their own references, or their own judgment. A pure "ok" is
|
|
17
|
-
accepted, but the protocol must have OFFERED the space for substance —
|
|
18
|
-
the questions must be open, not yes/no gates.
|
|
19
|
-
3. **The LLM updates the artifact and shows the delta.** The restatement,
|
|
20
|
-
analysis log, assumption list, or candidate matrix is edited and the chat
|
|
21
|
-
shows exactly which points changed because of the user's input.
|
|
22
|
-
|
|
23
|
-
High-impact points (D0, D-R, D2) may loop beats 2-3 as many times as needed
|
|
24
|
-
until the user says "可以了". Mathematical modeling is a deep activity;
|
|
25
|
-
"skim and start solving" is a protocol violation.
|
|
26
|
-
|
|
27
|
-
##
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
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
|
-
|
|
70
|
-
|
|
71
|
-
3.
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
|
|
122
|
-
|
|
123
|
-
-
|
|
124
|
-
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
|
|
138
|
-
|
|
139
|
-
|
|
140
|
-
|
|
141
|
-
|
|
142
|
-
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
|
|
146
|
-
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
-
|
|
159
|
-
|
|
160
|
-
|
|
161
|
-
|
|
162
|
-
|
|
163
|
-
|
|
1
|
+
# Interaction Protocol (v2)
|
|
2
|
+
|
|
3
|
+
Three interaction layers. Execution details stay autonomous; every
|
|
4
|
+
model-shaping decision is visible and user-owned.
|
|
5
|
+
|
|
6
|
+
## Deep-exchange protocol (v2.6)
|
|
7
|
+
|
|
8
|
+
Every L1 decision point follows a three-beat exchange, never a one-way
|
|
9
|
+
"here is my conclusion, confirm it":
|
|
10
|
+
|
|
11
|
+
1. **LLM presents a complete analysis with its evidence chain.** Every claim
|
|
12
|
+
inside the analysis carries its basis: an exact quote from the problem
|
|
13
|
+
text, a data statistic, a literature source id, or an explicit
|
|
14
|
+
"LLM judgment" marker. A naked conclusion is not a presentation.
|
|
15
|
+
2. **The user responds with substance**: confirmation, correction, background
|
|
16
|
+
knowledge, their own references, or their own judgment. A pure "ok" is
|
|
17
|
+
accepted, but the protocol must have OFFERED the space for substance —
|
|
18
|
+
the questions must be open, not yes/no gates.
|
|
19
|
+
3. **The LLM updates the artifact and shows the delta.** The restatement,
|
|
20
|
+
analysis log, assumption list, or candidate matrix is edited and the chat
|
|
21
|
+
shows exactly which points changed because of the user's input.
|
|
22
|
+
|
|
23
|
+
High-impact points (D0, D-R, D2) may loop beats 2-3 as many times as needed
|
|
24
|
+
until the user says "可以了". Mathematical modeling is a deep activity;
|
|
25
|
+
"skim and start solving" is a protocol violation.
|
|
26
|
+
|
|
27
|
+
## Chat-first phase presentation (v0.5)
|
|
28
|
+
|
|
29
|
+
每个重点环节必须先在聊天正文中展示完整、可读、可追问的文本,不能只写入 artifact,也不能只显示工具调用摘要。顺序固定为:
|
|
30
|
+
|
|
31
|
+
1. LLM 在聊天中给出完整内容、依据链、当前结论和可能被推翻的条件;
|
|
32
|
+
2. 给用户留下纠正、补充背景或确认的机会;
|
|
33
|
+
3. 用户确认后记录 chat presentation(content hash、呈现时间、用户确认时间和先于 artifact 的顺序);
|
|
34
|
+
4. 再写入 problem-brief、analysis log、assumptions、model、result 或 report artifact;
|
|
35
|
+
5. 最后才允许 run-state transition。
|
|
36
|
+
|
|
37
|
+
重点阶段与最小呈现内容如下:
|
|
38
|
+
|
|
39
|
+
| 阶段 | 聊天中必须完整展示 |
|
|
40
|
+
|---|---|
|
|
41
|
+
| D-R | 检索到的方法/背景、来源、适用范围和限制 |
|
|
42
|
+
| D0 / SCOPE_FROZEN | 六段式问题重述、依赖关系和待澄清问题 |
|
|
43
|
+
| INPUT_PROFILED | 每个附件的字段、单位、坐标系、范围和异常 |
|
|
44
|
+
| D2-G / CLAIMS_REGISTERED | 全局假设、依据、风险、Claims 和 Obligations |
|
|
45
|
+
| D3 / CANDIDATES_READY | 候选方向矩阵、选择理由、文献列和排除方向 |
|
|
46
|
+
| SP1… / ATTEMPT | 当前子问题的问题分析、输入、假设、目标和边界 |
|
|
47
|
+
| MODEL / EXECUTE | 完整模型方案、公式、参数、算法和预期输出 |
|
|
48
|
+
| VERIFICATION | 验证路径、反例、容差、结果和未覆盖范围 |
|
|
49
|
+
| EVALUATION / CORRECTION | 评价 finding、影响的 Claims、修正方案和 lineage |
|
|
50
|
+
| D4 / terminal | 本轮完整结果、证据摘要、局限和最终状态建议 |
|
|
51
|
+
|
|
52
|
+
run-state 只能验证结构化记录,不能直接观察聊天 UI;因此 chat presentation 是显式的 fail-closed 约束,而不是把写文件误认为已展示。缺失 presentation 时,真实 run 不得进入下一阶段。
|
|
53
|
+
|
|
54
|
+
## L1 decision points (MUST ask via the question tool)
|
|
55
|
+
|
|
56
|
+
| Point | Trigger | Question | Default |
|
|
57
|
+
|---|---|---|---|
|
|
58
|
+
| D0 问题重述 | intake complete | the six-section deep restatement below + open clarification questions | accept + no additions |
|
|
59
|
+
| D1 路由 | TRIAGE | task type (prediction/optimization/explanation/proof/…) + assurance mode (Fast/Standard/High-Assurance) | auto-routing result |
|
|
60
|
+
| D-R 文献研究 | CLAIMS_REGISTERED (before CANDIDATES_READY) | the literature list by direction (AI-found); user endorses / rejects / adds their own | accept list |
|
|
61
|
+
| D2-G 全局假设确认 | CLAIMS_REGISTERED (全景层) | the GLOBAL assumptions that hold for the whole problem (geometry, data, physical mechanism, numerical basis) — each with basis chain + risk | accept all |
|
|
62
|
+
| D2 子问题假设确认 | **each subproblem starts** | the assumptions for THIS subproblem only (S-class), each with statement + basis chain + risk | accept all |
|
|
63
|
+
| D2' 新假设插问 | mid-subproblem discovery that changes model structure | the new assumption + its effect | record-and-continue |
|
|
64
|
+
| D3 方向选择 | CANDIDATES_READY | candidate matrix with a literature column per direction; user picks or authorizes auto | baseline |
|
|
65
|
+
| D4 结果裁决 | VERIFY done | verdict + evidence digest + key intermediate results (residual/constraint-violation distributions, figure paths) + failure details | verdict-implied |
|
|
66
|
+
|
|
67
|
+
## D0 deep restatement — six sections (MANDATORY structure)
|
|
68
|
+
|
|
69
|
+
1. **题目要点摘录**:the problem's own numbers and constraints, quoted.
|
|
70
|
+
2. **背景解读**:the engineering/physical mechanism behind the problem.
|
|
71
|
+
3. **数据语义**:every attachment, column by column — meaning, units,
|
|
72
|
+
coordinate system, magnitudes; unreadable artifacts are flagged with the
|
|
73
|
+
minimum representation needed.
|
|
74
|
+
4. **隐含信息与歧义清单**:numbered; each entry = the LLM's reading + its
|
|
75
|
+
basis + the risk if the reading is wrong. This is the heart of the
|
|
76
|
+
exchange: the user corrects entries here.
|
|
77
|
+
5. **各子问题数学本质判定**:every sub-question of the problem — however
|
|
78
|
+
many there are (one or ten) — is classified (fitting/optimization/
|
|
79
|
+
geometric optics/simulation/…), with why.
|
|
80
|
+
5.5 **问间依赖关系**:which sub-questions depend on which (models, data,
|
|
81
|
+
verified claims reused downstream) — the整体感 guarantee: later questions
|
|
82
|
+
REFERENCE earlier verified results instead of re-deriving them.
|
|
83
|
+
6. **待澄清问题**:open questions inviting the user to add background,
|
|
84
|
+
correct a reading, or supply their own references — never a yes/no list.
|
|
85
|
+
|
|
86
|
+
After the user answers, problem-brief.md is updated and the delta is shown.
|
|
87
|
+
|
|
88
|
+
## D-R literature research (pre-modeling, mandatory)
|
|
89
|
+
|
|
90
|
+
1. The LLM searches by direction × method for principles and methods only —
|
|
91
|
+
engineering background, methodology papers, textbooks, official docs.
|
|
92
|
+
**Never** search for solutions/answers to the specific contest problem.
|
|
93
|
+
2. Findings are written to research/sources.jsonl (author/title/year/venue/
|
|
94
|
+
URL/retrieval date/excerpt with section or theorem/table location/mapped
|
|
95
|
+
direction). Every candidate in the method matrix gets a literature column
|
|
96
|
+
referencing these source ids; a direction with no literature must be
|
|
97
|
+
explicitly marked "原创方向" with its derivation basis.
|
|
98
|
+
3. The user is asked: endorse / reject / add their own references. User-added
|
|
99
|
+
references join sources.jsonl with the same fields.
|
|
100
|
+
4. The D-R interaction record goes into ledger.scope.interactions; the gate
|
|
101
|
+
refuses CANDIDATES_READY without it.
|
|
102
|
+
|
|
103
|
+
## Honest boundary of the gate
|
|
104
|
+
|
|
105
|
+
The gate is a MECHANISM guarantee, not an anti-fraud guarantee: it proves a
|
|
106
|
+
record exists, never that the record is true — every interaction record is
|
|
107
|
+
written by the agent itself. Falsified records are therefore out of the
|
|
108
|
+
gate's reach; the defense against them is the blind verifier subagent
|
|
109
|
+
(subagent-dispatch.md), which re-derives key claims from data alone, and the
|
|
110
|
+
artifact checks (research/sources.jsonl, attempts/N/report.md) that tie each
|
|
111
|
+
record to real files on disk.
|
|
112
|
+
|
|
113
|
+
## Rules
|
|
114
|
+
|
|
115
|
+
- D0/D1/D-R: once per task. D2/D3: once per subproblem. D2': only when a
|
|
116
|
+
discovery changes model structure. D4: once per attempt round.
|
|
117
|
+
- Every L1 record is appended to `ledger.scope.interactions` as
|
|
118
|
+
`{id, decisionPoint, question, options, userAnswer, timestamp, effectOnModel}`
|
|
119
|
+
or, for explicit auto authorization,
|
|
120
|
+
`{auto: true, decisionPoint, reason}`.
|
|
121
|
+
- Run the gate before every transition: `run-state.mjs gate <dir> --to <status> --reason "<...>"`.
|
|
122
|
+
The gate refuses SCOPE_FROZEN without D0+D1, CANDIDATES_READY without D-R,
|
|
123
|
+
ATTEMPT-from-CANDIDATES_READY without D3, terminals-from-VERIFY without D4,
|
|
124
|
+
and REVISE/RESEARCH (from VERIFY) whose reason fails to reference a
|
|
125
|
+
`decisionStack` entry id. The CLI `transition` command enforces the same
|
|
126
|
+
gate and has NO escape hatch. Every D4 record carries the attempt number it
|
|
127
|
+
adjudicates (`attempt: N`); the terminal gate requires the D4 for the
|
|
128
|
+
CURRENT attempt. ATTEMPT from CANDIDATES_READY requires `--subproblem <id>`.
|
|
129
|
+
Terminal gates additionally require `scope.cleanupPassed: true` and the
|
|
130
|
+
current attempt's report.md on disk. Mechanism-level tests and unattended
|
|
131
|
+
batch runs may declare `scope.contractExempt: true` — production modeling
|
|
132
|
+
must never set it.
|
|
133
|
+
|
|
134
|
+
In v0.5, report/evaluation/terminal transitions also read answer-coverage.json when the v3 ledger has registered requirements. Missing or stale mappings are hard blockers; partial mappings and explicit waivers are conditional-only. EVALUATE and CORRECTION_REQUIRED are non-final lifecycle states. An evaluation finding creates a correction lineage and never rewrites the parent run or silently upgrades a claim.
|
|
135
|
+
|
|
136
|
+
### Chat-first enforcement
|
|
137
|
+
|
|
138
|
+
For every major phase, the complete readable content must appear in the chat body before any phase artifact is written or state transition is attempted. The agent must show the evidence chain, current conclusion, limitations and falsification conditions, then invite user correction or confirmation. Only after confirmation may it call recordChatPresentation, write problem-brief/analysis/assumption/model/result/report artifacts, and invoke gate or transition.
|
|
139
|
+
|
|
140
|
+
A v3 real run has scope.chatFirstRequired=true and stores presentation records in ledger.scope.presentations. Each record must identify its stage, chat channel, content hash, presentedAt, userConfirmedAt, fullTextPresented=true and presentedBeforeArtifact=true. The machine gate cannot observe the UI directly, so it treats a missing or malformed record as a hard blocker and never treats a file-only artifact as proof of chat presentation. Major stages are D-R, D0, INPUT_PROFILED, D2-G, D3, each SPn, MODEL, VERIFICATION, EVALUATION, CORRECTION and D4.
|
|
141
|
+
|
|
142
|
+
## Phase pace — interactive beats between phases (v2.8)
|
|
143
|
+
|
|
144
|
+
The exposition is delivered PHASE BY PHASE, never as a firehose. The phase
|
|
145
|
+
sequence is: restatement → analysis → assumptions → modeling → solving →
|
|
146
|
+
verification → robustness → evaluation. Between every two phases there MUST
|
|
147
|
+
be a user interaction point: the completed phase is presented, one line asks
|
|
148
|
+
whether to proceed to the next phase, and the user may interrupt, ask for a
|
|
149
|
+
deeper explanation of any step of the just-finished phase, or contribute
|
|
150
|
+
knowledge. Sensitivity/robustness NEVER follows solving automatically — it
|
|
151
|
+
only starts after the verification phase, the user's go-ahead, and its own
|
|
152
|
+
D-interaction. Within a phase with ≥3 major steps, offer the user one
|
|
153
|
+
interruption opportunity after the first step.
|
|
154
|
+
|
|
155
|
+
## L2 display points (MUST show, never ask)
|
|
156
|
+
|
|
157
|
+
- After every attempt round: the 8-section runlog digest (see report-contract.md).
|
|
158
|
+
- Before every transition: one status line: `[状态] FROM → TO:一句话原因`.
|
|
159
|
+
- When starting any command estimated > 60 s: say what, how long, and what
|
|
160
|
+
continues in parallel (see tool-policy.md).
|
|
161
|
+
|
|
162
|
+
## L3 interruption
|
|
163
|
+
|
|
164
|
+
- The user may interrupt at ANY time ("停/换方向/改假设/结束").
|
|
165
|
+
- On interrupt: stop the current execution chain immediately, then return to
|
|
166
|
+
the nearest decision point on the stack and ask again.
|
|
167
|
+
- An interrupt never leaves the run directory inconsistent: run-state writes
|
|
168
|
+
are atomic and lock-guarded; in-flight background jobs are killed or awaited
|
|
169
|
+
before any transition is recorded.
|
|
170
|
+
|
|
171
|
+
## Decision stack and backtracking
|
|
172
|
+
|
|
173
|
+
- Every L1 decision also appends to `ledger.scope.decisionStack`:
|
|
174
|
+
`{id (e.g. D3-SP1), point, choice, at, reason}`.
|
|
175
|
+
- REVISE/RESEARCH (from VERIFY) reasons MUST reference the stack entry being
|
|
176
|
+
revisited (e.g. "回退到 D3-SP1:M2-area 违反 0.07% 边长约束,改 M1-cheb").
|
|
177
|
+
- A wrong direction returns to its fork point: FORK records the fork entry in
|
|
178
|
+
the stack; each failed branch leaves a wall memo before the next branch runs.
|
|
179
|
+
- Assumption revisions keep history: `revisionHistory: [{at, reason, changedTo}]`,
|
|
180
|
+
and every downstream claim/obligation that depended on the old assumption is
|
|
181
|
+
marked `stale: true` with the revising assumption id (see claims-evidence.md).
|
|
182
|
+
|
|
183
|
+
## Live documents (every phase can be refined later)
|
|
184
|
+
|
|
185
|
+
Every phase artifact is LIVE: problem-brief.md (restatement), analysisLog,
|
|
186
|
+
assumptions, sources.jsonl, methods.md, attempt reports. While solving,
|
|
187
|
+
anything discovered that shows an earlier phase was incomplete is patched
|
|
188
|
+
INCREMENTALLY — revision record + downstream stale marking — without
|
|
189
|
+
re-running completed unaffected work. This is the "解题中不断完善" rule.
|
|
190
|
+
|
|
191
|
+
## Rolling documents
|
|
192
|
+
|
|
193
|
+
- Problem restatement: written once at intake (problem-brief.md); only
|
|
194
|
+
referenced afterwards; a restatement edit re-opens scope freeze.
|
|
195
|
+
- Problem analysis: written per subproblem and appended on every discovery;
|
|
196
|
+
ledger.subproblems[].analysisLog = `[{at, entry, trigger}]`.
|
|
197
|
+
- Assumptions: registered per subproblem, revised incrementally; never assume
|
|
198
|
+
the full problem's assumptions are known up front.
|