CUMCM 워크플로우
중요한 주장을 공식 출처와 실제 실행에 추적 가능하게 유지하되, 모든 초안을 감사 패키지로 만들 필요는 없습니다.
아래의 모든 내용은 두 가지 규칙에 의해 결정됩니다.
- 도구는 기계적 사실을 기록합니다. 당신은 판단을 내립니다. 해시, 페이지 수, 종료 코드, 소스 스냅샷 또는 결과 값을 직접 입력하지 마세요.
record_run.py,index_result.py,record_compile.py및refresh_evidence.py가 이러한 작업을 관찰합니다. 당신은 문제 사실, 모델, 주장 및 논문을 작성합니다. - 모델은 늦게 선택되며, 선택은 증명되어야 합니다. 작업 모드는 초안 모델 계약을 수용합니다. 후보 모델을 지정하고, 어떤 증거가 모델을 구분할 수 있는지 말하고, 저렴한 탐색적 실행을 통해 평가한 후에만 하나를 선택하고 계약을 확정합니다.
시작 또는 재개
.cumcm/state.json을 찾습니다. 정확히0.6.0프로젝트를 재개합니다. 오래된 작업 공간은 지원되지 않습니다. 공식 파일로 새 프로젝트를 시작하세요.- 상태가 없고 사용자가 공식 파일을 제공하는 경우, 01-intake.md를 읽고 안전한 대상을 선택한 다음 사용자를 대신하여
scripts/init_project.py를 실행합니다. 사용자가 명령어를 조합하도록 하지 마세요. - 활성 단계 가이드와 단계를 넘을 때만 handoffs.md를 읽습니다. 새로운 작업은 전체 작업 공간이 아닌 핸드오프를 먼저 읽습니다.
- 여섯 가지 책임(조정, 모델링, 계산, 검증, 논문, 전달)을 구별하여 유지하십시오. 여러 개의 작은 스킬을 만들어 분리를 시뮬레이션하지 마십시오.
두 가지 조절 장치
mode(상태에 있음)는 무엇이 완료되어야 하는지를 결정합니다. --gate-mode는 인간 게이트가 적용되는지 여부를 결정합니다.
working: 빠른 모델링, 탐색적 계산, 디버깅. 공식 입력 보호, 실제 실행, 정확한 결과 로케이터 및 비-조작이 적용됩니다. 초안 모델 계약이면 충분합니다.CROSS_QUESTION_LEDGER.json은 선택 사항입니다. 단계 순서는 권고 사항입니다. 여기서enforce는 공식 승인이 아닌working_ready를 보고합니다.finalizing: 주장을 담은 결과를 확정합니다. 모델 계약이 완전해야 하며, 검증 계획이 공식 실행으로 기록된 어설션에 매핑되어야 합니다. 현재 단계 결정 및 스냅샷, 새로운 핸드오프, 제한된 독립 검토, 논문/PDF QA 및 전달 바인딩이 필요합니다. 요청된 단계를 포함한 모든 단계가 현재 수락된 결정과 함께passed상태가 아니면enforce는 통과할 수 없습니다.
scripts/set_mode.py로 전환합니다. v0.6에는 strict/sprint 프로필이 없습니다. 단일 규칙 세트가 적용됩니다.
인간이 개입해야 하는 곳
블록당 하나씩, 세 개의 체크포인트가 있으며, 각 체크포인트는 인간이 결정한 것뿐만 아니라 인간 앞에 무엇이 제시되었는지를 기록합니다. 아무것도 제시되지 않은 결정은 누군가가 살펴보았다는 증거가 아닙니다. 이 체크포인트는 세 가지 비용 단계 앞에 있습니다. 모델 선택을 거부하는 것은 대화를 요하고, 결론을 거부하는 것은 재계산을 요하고, 완성된 논문을 거부하는 것은 재작성을 요합니다.
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는 보고서입니다. 검토자 선택은 기록되지만 확인되지는 않습니다. 두 가지 절단 전환(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에 실행을 나열합니다. 그런 다음에만 선택된 모델이 공식 실행을 받습니다.
검사기는 이를 강제합니다. 정확히 하나의 후보만 selected(MODEL-E013)로 끝나야 하며, 선택은 이를 평가한 실행을 인용해야 하고(MODEL-W014), 선택 또는 거부된 후보는 기록된 이유가 필요하며(MODEL-E014), 후보를 구분할 것이 없는 후보는 플래그가 지정됩니다(MODEL-W012). working 모드에서는 경고이며, 확정 시 오류가 됩니다. cumcm_check.py는 model_candidates 아래에 비교 결과를 출력합니다.
이것이 의도적으로 하지 않는 두 가지는 다음과 같습니다. 하나가 분명히 옳을 때 둘 이상의 후보를 요구하지 않으며(이것은 MODEL-W007, 경고), 어떤 후보가 더 나은지 판단하지 않습니다 — 단지 기록된 증거에 대해 선택이 이루어졌다고 주장할 뿐입니다.
계산 기록
# 탐색적 실행은 기록하는 데 비용이 들지 않습니다
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 "최소 비용" --unit CNY --scope "선언된 후보만"
# 재실행은 후속을 추가합니다. 부모와 그 증거는 그대로 유지됩니다
python3 scripts/record_run.py --project <p> --rerun RUN-Q1-001 --official
python3 scripts/index_result.py --project <p> --follow-lineage
탐색적 실행은 기록되지만 신뢰되지 않으며 차단하지 않습니다. 탐색적 실행 내의 실패한 어설션이나 0이 아닌 종료 코드는 실험에 대한 사실일 뿐, 공식 체인에 대한 것이 아닙니다. 성공적인 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는 실패해야 합니다. 하나의 언어로 구현하고 공식적으로 실행하십시오. 사용자가 요청하지 않는 한 동등한 구현을 구축하지 마십시오.
증거 게이트
- 하드 불변 /
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을 수동 편집하는 것이 아니라 하나의 명령어입니다.
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은 증거에 중요한 식별에만 사용하십시오: 공식 출처, 공식 입력, 주장을 담은 출력, 간결한 스냅샷/핸드오프, 리뷰 패키지, 선택된 소스 트리 및 검토된 최종 PDF.
- 내부 ID, 증거 상태, 로컬 경로, 실행 범위 및 워크플로우 언어를 눈에 보이는 논문에 포함시키지 마십시오.
- 논문 핸드오프 제한은 지원되는 논문 적격 주장 제한, 현재 P1 우려 사항 및 명시적인 적용 가능성/가정/알려진 제한 필드에서만 비롯됩니다 — 모순된 주장이나 모델 범위가 아닙니다.
- 최종 PDF를 검토된 바이트와 컴파일에 사용된 정확한 편집 가능한 LaTeX 소스 스냅샷에 바인딩하십시오.
- 현재 공식 규칙 또는 템플릿이 없으면 전달을 차단합니다. 자율 검색 또는 제출을 승인하지 않습니다.
- 최종 전달에는 검토된 PDF, 편집 가능한 LaTeX 및 계산 소스가 별도의 역할로 포함됩니다.
기계 판독 가능 파일을 생성할 때는 artifact-contracts.md를 읽고, evidence-rules.md를 읽으십시오.