make-round

Motion verification is opt-in. Standalone make_round and verify_project default to false; pass --check-motion true to enable it. Inside Workshop, read the immutable run-root MAKE-OPTIONS.json: the tools inherit its check_motion value and reject contradictory flags. A missing options file in an older materialized run retains its mandatory motion policy. When false, skip motion sweeps and required animation/reconstruction/review, even if a manifest or assembly claims exist. Motion is unverified, never passed; do not claim assemblability or working motion from skipped evidence. Build, fit, print gates and still-image review remain required. These rules take precedence over motion-specific requirements in references and templates.

A correction carries unchanged parts forward. This is the default for workshop fix, recorded as carry_unchanged in the run-root MAKE-OPTIONS.json under schema_version: 2; motion_policy.carry_unchanged() reads it. It is false for every run with no source to carry from, and for every run created before the policy existed -- those have no schema-2 document, so a refreshed tool still reads them the way they were created. workshop fix --full declines it. The policy changes only what a round may CARRY FORWARD. It lowers no threshold, relaxes no gate and skips nothing about the assembly.

What it permits, and only after the changed-part set is established by building EVERY part and comparing its B-rep identity against the source's (ADR 0073 -- never STEP bytes, which an exporter can serialize differently for an unchanged shape, and never a shape reloaded from a STEP file, which does not hash like the one that was built):

• A part whose B-rep is identical to the source's needs no new isolated component round, even when its exported STEP bytes differ. The source archive's round history for that part is still exactly true of it, because a gate is a pure function of the shape it reads. Carry that history forward and record the B-rep hash it is carried on.
• Its per-part measure reports are carried forward the same way, unchanged.

gen --write --json reports each part's B-rep identity as identitySha256, alongside the exact installed build123d/cadquery-ocp versions it was computed under as toolchainVersions, computed on the shape it just built, never on an import. Before finalizing a round, write <cad_project_path>/component-identities.json naming, for every sealed .step Component, {"component_identities": {"<path>": "<identitySha256>", ...}, "toolchain": {"build123d": "<version>", "cadquery_ocp": "<version>"}} (paths relative to the product root, e.g. cad/part_belt_cell.step, the toolchainVersions object's own keys). The Make finalizer seals this into made.json as schema_version: 2's component_identities/toolchain fields -- this is what lets a later Correction Run skip rebuilding this archive's own Components (issue #64, ADR 0073's "Update from #60"). Leave the sidecar file unwritten for a round with no identitySha256 to report (an imported/committed STEP target only, or the DXF pipeline): the finalizer seals plain schema_version: 1, exactly as before.

For the source side of a Correction Run's comparison: read the source archive's make/made.json first. If it is schema_version: 2 and its toolchain matches this run's own installed build123d/cadquery-ocp versions exactly, use its component_identities[path] directly -- no rebuild. Otherwise (schema 1, sealed before this change, or a toolchain that does not match -- a sealed hash from a different OCCT is not comparable), get the source side by rebuilding the source's own part_<role>.step.py in a scratch copy of its make/ tree with the same gen --write --json and reading its identitySha256 there; the source's own generator sources and shared helpers are already inside the revision snapshot, so this needs no new input. There is no tolerance on this comparison: two hashes either match or they do not.