D107 — Fixture preparation by native conversion and ID repair

Decision

Fixture preparation privately converts with version-matched native LoadBoard/SaveBoard before repairing generated/zero/duplicate/missing identities and UUID-dependent item order, then refills and publishes the unrouted board last; source/human boards and rule bytes stay untouched

Alternatives

Repair IDs after the first refill; strip-only preparation; transplant PCBench quality/thermal-retention machinery

Reason

Native conversion can generate random item IDs or leave legacy zones sharing zero IDs; identity-dependent load order must be stable before native geometry/DRC. Failed preparation removes only its generated runnable artifacts because existing consumers do not read validity manifests. Repeated board/rule bytes, not native report hashes, are the reproducibility contract; fresh paired baselines are required for the changed prepared input (doc 10 §1)