Lucasuiii/cumcm-workflow

Was macht cumcm-workflow?

Halten Sie die Ansprüche nachvollziehbar zu offiziellen Quellen und zur tatsächlichen Ausführung, ohne jeden Entwurf in ein Prüfprotokoll zu verwandeln.

Zwei Regeln bestimmen alles Folgende:

1. Werkzeuge zeichnen Maschinenfakten auf; Sie schreiben das Urteil. Geben Sie niemals einen Hash, eine Seitenzahl, einen Exit-Code, einen Quellen-Snapshot oder einen Ergebniswert ein. record_run.py, index_result.py, record_compile.py und refresh_evidence.py erfassen diese. Sie schreiben Problemfakten, das Modell, Ansprüche und die Arbeit.
2. Das Modell wird spät gewählt, und die Wahl wird verdient. Der Arbeitsmodus akzeptiert einen Entwurf eines Modellvertrags. Sie nennen Kandidatenmodelle, legen fest, welche Belege sie unterscheiden würden, bewerten sie mit günstigen explorativen Läufen und wählen erst dann eines aus und frieren den Vertrag ein.

Starten oder fortsetzen

1. Finden Sie .cumcm/state.json. Setzen Sie ein exaktes 0.6.0-Projekt fort. Ältere Arbeitsbereiche werden nicht unterstützt; starten Sie ein neues Projekt aus den offiziellen Dateien.
2. Wenn kein Zustand existiert und der Benutzer offizielle Dateien bereitstellt, lesen Sie 01-intake.md, wählen Sie ein sicheres Ziel und führen Sie für sie scripts/init_project.py aus. Lassen Sie den Benutzer den Befehl nicht selbst zusammenstellen.
3. Lesen Sie nur die aktive Stufenanleitung plus handoffs.md beim Überschreiten von Stufen. Eine neue Aufgabe liest zuerst ihre Übergabe, nicht den gesamten Arbeitsbereich.
4. Halten Sie die sechs Verantwortlichkeiten getrennt: Orchestrierung, Modellierung, Berechnung, Validierung, Arbeit, Lieferung. Simulieren Sie keine Trennung, indem Sie viele kleine Skills erfinden.

Die zwei Stellschrauben

mode (im Zustand) entscheidet, was vollständig sein muss. --gate-mode entscheidet, ob menschliche Tore zählen.

• working: schnelle Modellierung, explorative Berechnung, Fehlersuche. Schutz offizieller Eingaben, tatsächliche Ausführung, exakte Ergebnis-Lokatoren und keine Fälschung werden durchgesetzt. Ein Entwurf eines Modellvertrags ist ausreichend; CROSS_QUESTION_LEDGER.json ist optional; die Stufenreihenfolge ist beratend. enforce meldet hier working_ready, niemals eine formale Genehmigung.
• finalizing: Friere anspruchsrelevante Ergebnisse ein. Der Modellvertrag muss vollständig sein und sein Verifikationsplan muss auf Behauptungen abbilden, die ein offizieller Lauf aufgezeichnet hat. Erfordert aktuelle Stufenentscheidungen und Snapshots, frische Übergaben, abgegrenzte unabhängige Überprüfung, Papier-/PDF-Qualitätssicherung und Lieferungsbindung. enforce kann nicht bestehen, es sei denn, jede Stufe bis zur angeforderten ist mit einer aktuellen akzeptierten Entscheidung als passed markiert.

Wechseln Sie mit scripts/set_mode.py. Es gibt in v0.6 kein strict/sprint-Profil; es gilt ein einziger Regelsatz.

Wo eine Person gefragt wird

Drei Prüfpunkte, einer pro Block, und jeder zeichnet auf, was der Person vorgelegt wurde, nicht nur, was sie entschieden hat. Eine Entscheidung ohne Präsentiertes ist kein Beleg dafür, dass jemand hingesehen hat. Sie sitzen vor den drei Kostenschritten: die Ablehnung einer Modellwahl kostet ein Gespräch, die Ablehnung einer Schlussfolgerung kostet eine Neuberechnung, die Ablehnung einer fertigen Arbeit kostet eine Neufassung.

• MODEL_CONTRACT.selection_check, bevor ein Kandidat selected wird: das Bewertungskriterium, die discriminating_evidence jedes Kandidaten und der scope, den der Gewinner beanspruchen wird. presented_candidate_ids muss jeden Kandidaten abdecken (MODEL-E018) – nur den Gewinner zu zeigen ist kein Vergleich.
• CLAIM_LEDGER.conclusion_check, vor validation-paper: die Schlussfolgerungen selbst – Anspruchstext, scope, Belegstatus, offene P0/P1. Keine Run-IDs, keine Hashes. presented_claim_ids muss jeden deklarierten Anspruch abdecken (CLAIM-E023). Dies ist der günstige Ort, um „Nein“ zu hören; derselbe Einwand kostet bei der Lieferung eine neu geschriebene Arbeit.
• DELIVERY_MANIFEST.final_check, vor der Einreichung: das fertige Objekt – gerenderte Seiten, die Antwort auf jedes Teilproblem, offene Ergebnisse. presented_pages muss jede gerenderte Seite abdecken (DELIVERY-E020), und human_user ist nicht beanspruchbar, wenn nichts präsentiert wurde (DELIVERY-E019).

Der Papierbericht trägt keine eigenen Genehmigungen: content_report und layout_report sind Berichte. Die Auswahl des Gutachters wird aufgezeichnet, nicht bestätigt – die Trennung erfolgt stattdessen durch die zwei Schnittübergänge (references/handoffs.md).

Stufenstatus sind not_started, in_progress, passed, needs_revision.

Rollen und Übergaben

Verantwortung	Hauptreferenz	Ausgehende Übergabe
Modellierung	02-problem-analysis.md, 03-model-design.md	modeling-computation
Berechnung	04-computation.md	computation-validation
Validierung	05-validation.md	validation-paper
Arbeit	06-paper-writing.md, latex-template.md	paper-delivery
Lieferung	07-compile-delivery.md	endgültiges Paket

Erstellen Sie Übergaben mit scripts/build_handoff.py. Sie enthalten kanonische Pfade, eine kompakte downstream-Nutzlast und einen upstream-Digest. Kopieren Sie niemals vollständige Protokolle, fehlgeschlagene Läufe, Debug-Verlauf oder alte Überprüfungsgespräche. Ein veralteter Digest erfordert einen Neubau.

Das Modell auswählen

Das Modelldesign wählt kein Modell aus. Es schlägt Kandidaten vor und legt fest, wie die Wahl getroffen wird:

"candidates": [
  {"candidate_id": "CAND-ENUM", "method": "complete enumeration",
   "why_considered": "die deklarierte Policy-Klasse ist endlich und klein",
   "discriminating_evidence": ["ob die gierige Auswahl dem aufgezählten Minimum entspricht"],
   "status": "under_evaluation"},
  {"candidate_id": "CAND-GREEDY", "method": "greedy first-fit",
   "why_considered": "konstante Zeit, ausreichend, wenn die Menge bereits nach Kosten geordnet ist",
   "discriminating_evidence": ["ob die gierige Auswahl dem aufgezählten Minimum entspricht"],
   "status": "under_evaluation"}
]

Dann entscheiden Sie mit Belegen und nicht mit einer Meinung:

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

Setzen Sie den Gewinner auf status: "selected", die anderen auf "rejected", geben Sie jedem eine decision_rationale, die sich auf das bezieht, was diese Läufe gezeigt haben, und listen Sie die Läufe in evaluation_run_ids auf. Erst dann erhält das ausgewählte Modell einen offiziellen Lauf.

Der Prüfer hält Sie daran fest: genau ein Kandidat darf selected enden (MODEL-E013), eine Auswahl muss einen Lauf zitieren, der sie bewertet hat (MODEL-W014), ein ausgewählter oder abgelehnter Kandidat benötigt einen aufgezeichneten Grund (MODEL-E014), und ein Kandidat, der nichts hat, was ihn unterscheidet, wird gekennzeichnet (MODEL-W012). Im working-Modus sind dies Warnungen; das Einfrieren macht sie zu Fehlern. cumcm_check.py gibt den Vergleich unter model_candidates aus.

Zwei Dinge, die dies bewusst nicht tut: Es erfordert nicht mehr als einen Kandidaten, wenn einer offensichtlich richtig ist (das ist MODEL-W007, eine Warnung), und es bewertet nicht, welcher Kandidat besser ist – es besteht nur darauf, dass die Wahl anhand aufgezeichneter Belege getroffen wurde.

Aufzeichnung der Berechnung

# Exploration kostet nichts bei der Aufzeichnung
python3 scripts/record_run.py --project <p> -- python3 code/try.py

# Das Einfrieren eines Laufs für formale Ergebnisse kostet einige Deklarationen
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 "machbarkeit=bestanden" -- python3 code/solve.py

# Der Wert wird aus der Ausgabe gelesen, niemals transkribiert
python3 scripts/index_result.py --project <p> --result-id RES-Q1-001 \
  --run RUN-Q1-001 --locator results/q1.json#/minimum_cost \
  --name "Mindestkosten" --unit CNY --scope "nur deklarierte Kandidaten"

# Ein erneuter Lauf fügt einen Nachfolger an; das Elternteil und seine Belege bleiben unberührt
python3 scripts/record_run.py --project <p> --rerun RUN-Q1-001 --official
python3 scripts/index_result.py --project <p> --follow-lineage

Explorative Läufe werden aufgezeichnet, niemals vertraut und blockieren niemals: Eine fehlgeschlagene Behauptung oder ein Exit-Code ungleich Null innerhalb eines solchen Laufs ist eine Tatsache über das Experiment, nicht über die formale Kette. Nur ein erfolgreicher official_run: true-Lauf darf ein formales Ergebnis stützen.

Läufe sind append-only. --rerun fügt RUN-Q1-002 mit parent_run_id: RUN-Q1-001 an; es überschreibt niemals, da das Elternteil die einzige Aufzeichnung dessen ist, was der ersetzte Lauf ausgeführt und produziert hat. Jeder Lauf friert seine deklarierten Quellen und Ausgaben in runs/<id>/source/… und runs/<id>/outputs/… ein, spiegelt das ursprüngliche Layout wider und hasht diese Kopien – so bleibt ein erhaltener Lauf unabhängig von Arbeitsbereichsänderungen überprüfbar, und output_locator benennt eine unveränderliche Datei.

Ein Lauf darf nur beanspruchen, was er produziert und was er verifiziert hat: Der Aufzeichner vergleicht den Zeitstempel jeder deklarierten Ausgabe während der Ausführung und weigert sich, eine übrig gebliebene Datei als anspruchsrelevantes Beleg dieses Laufs zu erfassen, und ein erneuter Lauf erbt niemals die Behauptungsurteile seines Elternteils. Nur ein erfolgreicher offizieller erneuter Lauf ersetzt sein Elternteil, und jeder formale Konsument löst den aktuellen Lauf durch denselben Code auf.

Das schwächt die Drifterkennung nicht, sondern schärft sie. RUN-E020 vergleicht nun die eingefrorene Kopie mit der Live-Datei und sagt, dass der Arbeitsbaum sich von dem Lauf entfernt hat, der Ihre Ergebnisse stützt; ersetzte Läufe sind ausgenommen, und das Ändern einer eingefrorenen Kopie ist RUN-E021. Die Ersetzung wird aus der Elternkette abgeleitet und niemals zurückgeschrieben – das Stempeln des alten Manifests würde seinen Hash ändern und jede daran gebundene Entscheidung ungültig machen. RESULT-E017 erkennt ein Ergebnis, das immer noch einen ersetzten Lauf zitiert; index_result.py --follow-lineage zeigt es explizit neu an, da welcher Lauf einen Anspruch stützt, ein Urteil und keine Maschinentatsache ist.

Auswahl eines Backends

Der Projektstatus standardmäßig auf {"preferred":"matlab","fallback":"python","selection":"auto"}. Verwenden Sie scripts/backend_selection.py oder dieselben Kriterien: numerische Verfahren, Optimierung, ODE/PDE, Signalverarbeitung, Datenbereinigung, Excel/CSV, maschinelles Lernen, verfügbare Toolboxen, vorhandener Code, Komplexität, Laufzeitstabilität. Die MATLAB-Präferenz bricht nur Gleichstände. Ein nicht verfügbares bevorzugtes Backend kann auf das Fallback zurückfallen; eine nicht verfügbare Aufgabe required_backend muss fehlschlagen. Implementieren Sie eine Sprache und führen Sie sie offiziell aus. Bauen Sie keine Paritätsimplementierungen, es sei denn, der Benutzer fordert dies.

Beleg-Tore

• harte Invariante / P0: falsche Daten oder Berechnung, Aufgabeninkongruenz (eine Fähigkeit, die niemand übernommen hat oder die noch unvollendet ist, wenn die Arbeit sich selbst als endgültig bezeichnet, ist die maschinell sichtbare Hälfte davon: CAP-E013, CAP-E014), ein Anspruch, dessen deklarierter Umfang den tatsächlich verifizierten Bereich überschreitet, Code/Ergebnis/Arbeitsabweichung, eine Annahme, die einer angegebenen Bedingung widerspricht, veraltete Provenienz, gefälschte Genehmigung oder Überprüfung, simulierte Daten, die als beobachtet dargestellt werden, Endversionskonflikt. Diese blockieren.
• Warnung / P1, bewertet innerhalb des verifizierten Bereichs: starke Annahmen, schwache Baseline, dünnere Validierung oder Sensitivität als ideal, eingeschränkte Anpassung, dünner Abschnitt. Sichtbar, niemals blockierend.
• Vorschlag / P2: Formulierung, Layout, optionale Grafik, zusätzliches Experiment. Nicht im Tor.

Unabhängige Validierung verwendet accepted, accepted_with_concerns, revision_required, inconclusive. Nur ein offenes P0 erlaubt revision_required. Nachdem eine vollständige Überprüfung P0-Probleme gefunden hat, wird das nächste Paket standardmäßig zu einer gezielten erneuten Überprüfung genau dieser Ergebnisse.

Das Überprüfungspaket kopiert nur kanonische Belege für formal indexierte Ergebnisse und zeichnet context_excluded auf – die vorherige Argumentation, die es physisch ausgelassen hat. Es beansprucht nicht, dass der Gutachter keine Meinung hat. Die Ergebnisvorlage lässt jedes Unabhängigkeitsfeld null: Der Gutachter muss sie behaupten, und ein null führt zu IREVIEW-E027. Der Benutzer bestätigt den Gutachter nicht mehr; die Trennung erfolgt stattdessen durch den Schnitt – computation-validation und validation-paper tragen die Aufgabe, die sie erstellt hat, und eine verbrauchende Aufgabe, die übereinstimmt, ist HANDOFF-E010. Siehe references/handoffs.md.

Iterieren

Das Wiedereröffnen einer vorgelagerten Stufe ist ein Befehl, keine manuelle Bearbeitung von 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-Modell passt nicht zum beobachteten Regime"

Das macht die Stufe und alles nachgelagerte ungültig. Um herauszufinden, was eine Änderung tatsächlich kostet, bevor Sie etwas wiederholen:

python3 scripts/plan_redo.py --project <p> --changed code/solve_q2.py

plan_redo.py durchläuft source -> official run -> result -> claim -> section -> PDF und nennt die spezifischen Läufe, Ergebnisse und Abschnitte, die betroffen sind – und diejenigen, die es nicht sind. Es unterdrückt nie eine Prüfung; cumcm_check.py validiert dennoch alles bis zur angeforderten Stufe, weil das günstig ist. Die teure Arbeit ist das erneute Ausführen, erneute Überprüfen und erneute Schreiben, und das ist es, was der Plan absteckt.

Wettbewerbsinvarianten

• Bewahren und byte-identifizieren Sie offizielle Quellen. OCR lenkt die Aufmerksamkeit; gerenderte Seiten entscheiden über Formeln, Tabellen und mehrdeutige Notation.
• Erfinden Sie niemals beobachtete Daten, Genehmigungen, unabhängige Überprüfungen oder erfolgreiche Ausführungen. Kennzeichnen Sie echte Simulationen und zeichnen Sie deren Generator und Seed auf.
• Halten Sie das mathematische Modell und die Ergebnisverträge sprachneutral.
• Verwenden Sie SHA-256 nur für belegkritische Identität: offizielle Quellen, formale Eingaben, anspruchsrelevante Ausgaben, kompakte Snapshots/Übergaben, Überprüfungspakete, ausgewählte Quellbäume und das überprüfte endgültige PDF.
• Halten Sie interne IDs, Belegzustände, lokale Pfade, Laufabdeckung und Workflow-Sprache aus der sichtbaren Arbeit heraus.
• Beschränkungen der Papierübergabe ergeben sich nur aus unterstützten papierberechtigten Anspruchseinschränkungen, aktuellen P1-Bedenken und expliziten Feldern für Anwendbarkeit/Annahmen/bekannte Einschränkungen – nicht aus widersprüchlichen Ansprüchen oder Modellumfang.
• Binden Sie das endgültige PDF an seine überprüften Bytes und an die exakte bearbeitbare LaTeX-Quell-Snapshot, die für die Kompilierung verwendet wurde.
• Fehlende aktuelle offizielle Regeln oder Vorlagen blockieren die Lieferung; sie autorisieren keine autonome Suche oder Einreichung.
• Die endgültige Lieferung enthält das überprüfte PDF, bearbeitbaren LaTeX und Berechnungsquellen als separate Rollen.

Lesen Sie artifact-contracts.md beim Erstellen maschinenlesbarer Dateien und evidence-rules.md für die vollständigen Belegregeln.

Lesen Sie troubleshooting.md für häufige Probleme und deren Behebung.