forge

forge

!checklist init ${CLAUDE_SKILL_DIR} --force

The method survived the tournament; the protocol is frozen. forge is the lens you hold over the run — the step where the design becomes real, executed, recorded evidence. It is the fourth skill of the inquiry suite: it owns step four of doing computational research — hardening the surviving method into production experiment code and running it to produce confirmation-grade results. It audits (and guides you to run) a gated pipeline, and it will not advance past a GATE until the checklist tool clears it. That gate enforces order — each step done before the next — not the substance of the work inside it; the tool structures the discipline, it does not audit it, so the rigor is yours to supply.

The one mental shift everything hangs on — the run is frozen, and the agent becomes an operator. Up to here the agent was a builder; from here it is an operator. The code is frozen, the agent holds read and execute only — no write, and it does not get to "helpfully fix" a number that looks wrong or nudge a validation threshold until the check passes. The reason is mechanical, not moral: a coding agent's gradient points at "the test passed", not "the result is correct", and the shortest path to a passing validator is to edit the validator. Permission isolation closes that path in a way that telling it not to never will. And the whole step has a single governing standard — one-command regeneration: every table and figure the paper will contain rebuilds from the raw results by one command, with no hand-edited number anywhere. That one bar buys reproducibility, anti-data-rot, and most of the reproduction package at the same time. The arc is: harden the MVP → wire provenance into every run → run idempotently → operate (don't edit) → keep the results uncorrupted → regenerate everything from one command.

The agent is the means, not the author of the numbers. Here its job is the dull, well-bounded labor: the hardening refactor (under your frozen interface), submitting the task grid, watching logs, retrying by the rules, drafting progress and anomaly reports, and running the clean-environment repro smoke test. It is not the author of the results and not permitted to change what the experiment measures. Its signature failure in this step is the one above — silencing a check rather than reporting the bug under it — so the defense is built into the permissions, and every produced solution is re-checked by an independent feasibility checker that shares no logic with any solver (a number that "soars" is, nine times in ten, an infeasible solution the agent's code produced and its own code blessed).

What you cannot delegate — the run shrinks the human to two events. Done right, this step automates almost everything; what stays yours is exactly two kinds of decision. (1) Protocol-change decisions — whether a discovered bug forces a full rerun, whether to add seeds, whether the frozen interface must be cut to a new version. (2) Anomalies the agent cannot auto-attribute — the failure that is neither a clean resource error nor a clean code error, the result that is suspicious but feasible. Everything else should be the agent turning. Outsource these two and you have automated your way to a confidently-recorded wrong number.

What "done" looks like — four conditions, not "the jobs finished". The run is over when: every number the protocol calls for is on disk and version-consistent, any table or figure regenerates from the raw results by one command, the clean-environment reproduction smoke test passes, and the 历程 (lab-notebook) evidence chain is complete — each formal run traceable to its run id, commit, and seed. If you have those four, stop running. "The cluster jobs all finished" is not the terminus; the regenerable, reproducible, traceable evidence base is.