Review of the atomic Apply found freshness gaps:
- A drawing's cutoff classification decides lead, material, obstacle and
dependency treatment but was not captured; changing it after planning
still applied the old proposal.
- Part and plate cutting settings were compared by reference only, so an
in-place edit after capture applied (and a regenerated part overwrote
it); plate settings were not compared at all. Settings are now captured
as an exact public-state fingerprint.
- A live program whose instruction list was set to null made Apply throw
instead of returning Stale, and a respelled key in a case-insensitive
binding dictionary compared equal.
Caller-confirmed planning settings remain planning input: editing them
after capture does not stale the plan and does not leak into the result.
Plate-scoped cutting plan requests now record the plate's exact state at
capture, and CuttingPlanService.Apply installs Ready, replayed proposals
for a whole scope at once:
- Any change after capture (order, pose bits, program reference or
in-place content, drawing program, lock/lead-in flags, settings,
quantity, size, quadrant or cutoff definitions) returns Stale with
nothing changed.
- Order changes without PartAdded/PartRemoved, so drawing quantities and
sentinel plates are untouched; ObservableList.Reorder exposes the same
operation and Plate.PartsReordered is raised once per changed plate.
- Regenerated parts receive owned copies of the replayed program and of
the settings captured with the request; fixed programs stay in place.
- An install failure restores every plate exactly; an observer failure
after publication is reported as a refresh error, not a rollback.
aj