CUMCM ワークフロー
重要な主張を公式ソースと実際の実行結果にトレース可能にし、すべてのドラフトを監査パッケージに変えることなく維持します。
以下の2つのルールがすべてを形作ります。
- ツールは機械的事実を記録し、あなたは判断を記述します。 ハッシュ、ページ数、終了コード、ソーススナップショット、結果値などを手動で入力することは決してありません。
record_run.py、index_result.py、record_compile.py、refresh_evidence.pyがそれらを監視します。あなたは問題の事実、モデル、主張、そして論文を記述します。 - モデルは後で選択され、その選択はエビデンスによって正当化されます。 作業モードはドラフトモデル契約を受け入れます。候補モデルを挙げ、それらを区別するエビデンスを特定し、安価な探索的実行で評価し、その後にのみ1つを選択して契約を確定します。
開始または再開
.cumcm/state.jsonを見つけます。0.6.0プロジェクトを厳密に再開します。古いワークスペースはサポートされていません。公式ファイルから新しいプロジェクトを開始してください。- 状態が存在せず、ユーザーが公式ファイルを提供した場合、01-intake.md を読み、安全なターゲットを選択し、ユーザーに代わって
scripts/init_project.pyを実行します。ユーザーにコマンドを組み立てさせないでください。 - アクティブなステージガイドと、ステージをまたぐ場合の handoffs.md のみを読みます。新しいタスクは、ワークスペース全体ではなく、まずそのハンドオフを読みます。
- 6つの責任（オーケストレーター、モデリング、計算、検証、論文、納品）を明確に区別します。多数の小さなスキルを発明することで分離をシミュレートしないでください。
2つのノブ
mode（状態内）は何を完了しなければならないかを決定します。--gate-mode は人間によるゲートがカウントされるかどうかを決定します。
working: 高速モデリング、探索的計算、デバッグ。公式入力の保護、実際の実行、正確な結果ロケーター、捏造禁止が適用されます。ドラフトモデル契約で十分です。CROSS_QUESTION_LEDGER.jsonはオプションです。ステージの順序は参考です。enforceはここではworking_readyを報告し、正式な承認は決して報告しません。finalizing: 主張を含む結果を確定します。モデル契約は完全であり、その検証計画は公式実行が記録したアサーションにマッピングできなければなりません。現在のステージの決定とスナップショット、新しいハンドオフ、範囲指定された独立レビュー、論文/PDFのQA、納品のバインディングが必要です。enforceは、要求されたステージまでのすべてのステージが、最新の承認された決定でpassed状態でない限り、合格できません。
scripts/set_mode.py で切り替えます。v0.6には strict/sprint プロファイルはありません。単一のルールセットが適用されます。
人間が関与するポイント
ブロックごとに3つのチェックポイントがあり、それぞれが人間の前に提示された内容（決定だけでなく）を記録します。何も提示されていない決定は、誰も確認したという証拠にはなりません。これらは3つのコストステップの前にあります。モデル選択の拒否は会話のコスト、結論の拒否は再計算のコスト、完成した論文の拒否は書き直しのコストがかかります。
MODEL_CONTRACT.selection_check、候補がselectedになる前: 判断基準、各候補のdiscriminating_evidence、勝者が主張するscope。presented_candidate_idsはすべての候補をカバーしなければなりません（MODEL-E018）— 勝者のみを表示するのは比較ではありません。CLAIM_LEDGER.conclusion_check、validation-paperの前: 結論自体—主張テキスト、scope、エビデンス状態、未解決のP0/P1。実行IDやハッシュは含みません。presented_claim_idsはすべての宣言された主張をカバーしなければなりません（CLAIM-E023）。これは「ノー」を聞くための安価な場所です。納品時に同じ異議が発生すると、論文の書き直しになります。DELIVERY_MANIFEST.final_check、提出前: 完成したオブジェクト—レンダリングされたページ、各サブ問題への回答、未解決の発見事項。presented_pagesはレンダリングされたすべてのページをカバーしなければならず（DELIVERY-E020）、human_userは何も提示されていない状態では主張できません（DELIVERY-E019）。
ペーパーレポートはそれ自体では承認を持ちません。content_report と layout_report はレポートです。レビュアーの選択は記録され、確認されません—分離は代わりに2つのカットトランジション（references/handoffs.md）から生じます。
ステージステータスは not_started、in_progress、passed、needs_revision です。
役割とハンドオフ
| 責任 | 主な参照 | 送信ハンドオフ |
|---|---|---|
| モデリング | 02-problem-analysis.md, 03-model-design.md | modeling-computation |
| 計算 | 04-computation.md | computation-validation |
| 検証 | 05-validation.md | validation-paper |
| 論文 | 06-paper-writing.md, latex-template.md | paper-delivery |
| 納品 | 07-compile-delivery.md | 最終パッケージ |
scripts/build_handoff.py でハンドオフを構築します。これらは、正規パス、コンパクトな下流ペイロード、上流ダイジェストを運びます。完全なログ、失敗した実行、デバッグ履歴、古いレビュー会話をコピーすることは決してありません。古いダイジェストは再構築が必要です。
モデルの選択
モデル設計はモデルを選択しません。候補を提案し、選択がどのように決定されるかを示します。
"candidates": [
{"candidate_id": "CAND-ENUM", "method": "complete enumeration",
"why_considered": "宣言されたポリシークラスは有限で小さい",
"discriminating_evidence": ["greedy選択が列挙された最小値と等しいかどうか"],
"status": "under_evaluation"},
{"candidate_id": "CAND-GREEDY", "method": "greedy first-fit",
"why_considered": "定数時間、セットがすでにコスト順に並んでいれば十分",
"discriminating_evidence": ["greedy選択が列挙された最小値と等しいかどうか"],
"status": "under_evaluation"}
]
次に、意見ではなくエビデンスで決着をつけます。
python3 scripts/record_run.py --project <p> --candidate CAND-ENUM -- python3 code/enum.py
python3 scripts/record_run.py --project <p> --candidate CAND-GREEDY -- python3 code/greedy.py
勝者を status: "selected" に、それ以外を "rejected" に設定し、それぞれにそれらの実行が示したことを参照する decision_rationale を与え、実行を evaluation_run_ids にリストします。その後でのみ、選択されたモデルは公式実行を受け取ります。
チェッカーはこれを強制します。ちょうど1つの候補が selected になることができ（MODEL-E013）、選択はそれを評価した実行を引用しなければならず（MODEL-W014）、選択または拒否された候補には記録された理由が必要です（MODEL-E014）。また、それを区別するものがない候補はフラグが立てられます（MODEL-W012）。working ではこれらは警告です。凍結するとエラーになります。cumcm_check.py は model_candidates の下に比較を出力します。
これが意図的に行わないことが2つあります。1つは、1つの候補が明らかに正しい場合に複数の候補を要求しないこと（MODEL-W007、警告）。もう1つは、どの候補が優れているかを判断しないことです。それは、選択が記録されたエビデンスに照らして行われたことのみを要求します。
計算の記録
# 探索には記録コストはかからない
python3 scripts/record_run.py --project <p> -- python3 code/try.py
# 正式な結果のために実行を凍結するには、いくつかの宣言が必要
python3 scripts/record_run.py --project <p> --official \
--capability CAP-Q1-001 --source code/solve.py \
--input data/q1.csv:formal --output results/q1.json:claim \
--assert "feasibility=pass" -- python3 code/solve.py
# 値は出力から読み取られ、決して書き写されない
python3 scripts/index_result.py --project <p> --result-id RES-Q1-001 \
--run RUN-Q1-001 --locator results/q1.json#/minimum_cost \
--name "Minimum cost" --unit CNY --scope "declared candidates only"
# 再実行は後続を追加する。親とそのエビデンスは変更されない
python3 scripts/record_run.py --project <p> --rerun RUN-Q1-001 --official
python3 scripts/index_result.py --project <p> --follow-lineage
探索的実行は記録され、信頼されず、決してブロックしません。その内部の失敗したアサーションや非ゼロの終了コードは、実験に関する事実であり、正式なチェーンに関するものではありません。成功した official_run: true の実行のみが正式な結果をサポートできます。
実行は追加専用です。--rerun は parent_run_id: RUN-Q1-001 を持つ RUN-Q1-002 を追加します。上書きは決してしません。親が、置き換えられた実行が実行し生成したものの唯一の記録だからです。各実行は、宣言されたソースと出力を runs/<id>/source/… および runs/<id>/outputs/… に、元のレイアウトをミラーリングして凍結し、それらのコピーをハッシュします。そのため、ワークスペースがどのように変化しても、保存された実行は検証可能なままです。output_locator は不変のファイルを指定します。
実行は、それが生成し検証したもののみを主張できます。レコーダーは、宣言されたすべての出力のタイムスタンプを実行全体で比較し、残されたファイルをこの実行の主張を含むエビデンスとして記録することを拒否します。再実行は、その親のアサーション評決を決して継承しません。成功した公式再実行のみがその親を置き換え、すべての正式なコンシューマーは同じコードを通じて現在の実行を解決します。
これはドリフト検出を弱めるのではなく、強化します。RUN-E020 は現在、凍結されたコピーをライブファイルと比較し、ワーキングツリーが結果を支える実行から離れて進んだことを示します。置き換えられた実行は免除され、凍結されたコピーを変更することは RUN-E021 です。置き換えは親チェーンから導出され、決して書き戻されません。古いマニフェストにスタンプを押すと、そのハッシュが変更され、それにバインドされたすべての決定が古くなります。RESULT-E017 は、まだ置き換えられた実行を引用している結果をキャッチします。index_result.py --follow-lineage はそれを明示的に再ポイントします。なぜなら、どの実行が主張をバックアップするかは、機械的事実ではなく判断だからです。
バックエンドの選択
プロジェクト状態のデフォルトは {"preferred":"matlab","fallback":"python","selection":"auto"} です。scripts/backend_selection.py または同じ基準を使用します。数値手法、最適化、ODE/PDE、信号処理、データクリーニング、Excel/CSV、機械学習、利用可能なツールボックス、既存のコード、複雑さ、実行時の安定性。MATLABの優先は同点の場合のみ解消します。利用できない優先バックエンドはフォールバックする場合があります。利用できないタスク required_backend は失敗しなければなりません。1つの言語を実装し、公式に実行します。ユーザーが要求しない限り、パリティ実装を構築しないでください。
エビデンスゲート
- ハード不変条件 /
P0: 間違ったデータまたは計算、タスクの不一致（誰も引き受けなかった能力、または論文が最終版と自称するときにまだ未完了の能力は、この機械的に可視な半分です：CAP-E013、CAP-E014）、宣言された範囲が実際に検証された範囲を超える主張、コード/結果/論文の不一致、記述された条件と矛盾する仮定、古い証明、捏造された承認またはレビュー、観測データとして提示されたシミュレーションデータ、最終バージョンの不一致。これらはブロックします。 - 警告 /
P1、検証された範囲内で判断: 強い仮定、弱いベースライン、理想よりも薄い検証または感度分析、限定的な適合、薄いセクション。可視であり、ブロックはしません。 - 提案 /
P2: 文言、レイアウト、オプションのチャート、追加実験。ゲートには含まれません。
独立検証は accepted、accepted_with_concerns、revision_required、inconclusive を使用します。未解決のP0のみが revision_required を許可します。完全なレビューでP0の問題が見つかった後、次のパッケージはデフォルトでそれらの発見事項に焦点を当てた対象を絞った再レビューになります。
レビューパッケージは、正式にインデックスされた結果の正規エビデンスのみをコピーし、context_excluded を記録します—物理的に除外した以前の推論です。レビュアーが意見を持たないと主張することはありません。結果テンプレートはすべての独立性フィールドを null のままにします。レビュアーはそれらを主張しなければならず、nullは IREVIEW-E027 で失敗します。ユーザーはもはやレビュアーを確認しません。分離は代わりにカットから生じます—computation-validation と validation-paper はそれらを構築したタスクを運び、一致するコンシューミングタスクは HANDOFF-E010 です。references/handoffs.md を参照してください。
反復
上流ステージを再開することは、state.json を手動で編集するのではなく、1つのコマンドです。
python3 scripts/record_decision.py --project <p> --stage model-design \
--decision revision_requested --decision-id DEC-007 --reviewer <name> \
--task-turn-ref <ref> --summary "Q2モデルは観測されたレジームに適合しない"
これにより、そのステージとそれより下流のすべてが無効になります。何かをやり直す前に、変更の実際のコストを調べるには：
python3 scripts/plan_redo.py --project <p> --changed code/solve_q2.py
plan_redo.py は source -> official run -> result -> claim -> section -> PDF を辿り、影響を受ける特定の実行、発見事項、セクション、および影響を受けないものを特定します。チェックを抑制することは決してありません。cumcm_check.py は要求されたステージまですべてを検証し続けます。それは安価だからです。高価な作業は再実行、再レビュー、再書き込みであり、それが計画の範囲です。
コンテストの不変条件
- 公式ソースを保存し、バイト単位で識別します。OCRは注意を向けます。レンダリングされたページが数式、表、あいまいな表記を決定します。
- 観測データ、承認、独立レビュー、または成功した実行を決して捏造しないでください。本物のシミュレーションにはラベルを付け、その生成器とシードを記録してください。
- 数学モデルと結果契約は言語に依存しないように保ちます。
- SHA-256はエビデンス上重要なIDにのみ使用します。公式ソース、正式な入力、主張を含む出力、コンパクトなスナップショット/ハンドオフ、レビューパッケージ、選択されたソースツリー、レビュー済みの最終PDF。
- 内部ID、エビデンス状態、ローカルパス、実行カバレッジ、ワークフロー言語を可視の論文から遠ざけます。
- 論文ハンドオフの制限は、サポートされている論文適格主張の制限、現在のP1懸念事項、明示的な適用可能性/仮定/既知の制限フィールドからのみ生じます—矛盾する主張やモデル範囲からは生じません。
- 最終PDFを、レビューされたバイトと、コンパイルに使用された正確な編集可能なLaTeXソーススナップショットにバインドします。
- 現在の公式ルールまたはテンプレートが欠落している場合、納品はブロックされます。自律的な検索や提出は許可されません。
- 最終納品には、レビュー済みPDF、編集可能なLaTeX、計算ソースが別々のロールとして含まれます。
機械可読ファイルを作成する際は artifact-contracts.md を、レビューパッケージ規約については evidence-rules.md を読んでください。