Job-level material pick + one-click APPLY TOOLPATHS on the part list -- material stays a fact of the PART, skip-and-name at a different material, the pack's mixed-material gate (Jordan 2026-09-20, 'Go ahead and build 1 to 3'); grouped per-material packing = the parked future road (his 'I'm going to think more about mixing materials')

kerfmaster pin list · UI / workflow decisions

recordmixedStates what the code does today. Auditable against the code — this is the only type that can go stale.

Content last changed 2026-09-20 — computed from the item itself, not typed.

BUILT 2026-09-20, the ruled 1-to-3 scope. THE DATA-MODEL ANSWER TO HIS QUESTION 4: material stays a fact of the PART (each part's own review already stores it -- true before this build); the list-level picker is a CONVENIENCE THAT FILLS PARTS, never a job property that binds them, so Jordan's one-material-per-job world and a mixed shop's world are the same data model, no wizard question needed. (1) SERVER door POST /api/jobs//plassign {material, post, machine, jobs?, overwrite?}: plans every listed part through the SAME road a by-hand review runs -- parse + heal + healedits, the part's recorded tooling-doc overrides riding in (tooling_doc.overrides_from -- an operator edit is never dropped silently; proven in the suite: a lead_length 0.12 operator override survives the batch re-plan with source 'operator'), rules.check_drag over the Rev2 row, _finish_review the one finisher (skip_if_same) -- batch and by-hand review can never disagree. One table read up front so a blank row refuses the whole batch in the table's own words, never N identical refusals. Per-part refusals (no healed geometry, engine miss) land named in the 200 reply without stopping the batch. body.jobs = the on-screen refs so unsaved draft rows ride too; the picked material/post/machine persist onto partlist.json as the pack's seed (rows untouched -- deliberately NOT the list-save stale drop; a packed layout stays, the recorded tooling_fp/plans_match machinery owns staleness). packed_at heads-up in the reply when a live pack was built at another material. plassign joins UNDO_DOORS ('Toolpath assignment', partlist) + UNDO_HEAVY (N re-plans, cross-job by construction). (2) SKIP-AND-NAME (his answer 4): a part already reviewed at a DIFFERENT material is skipped and named with its own material; overwrite is an explicit second click (body.overwrite). CLIENT: 'Apply toolpaths to all parts' button beside the existing machine x material picker on the Part list drawer; the skip banner names every skipped part and carries the 'Overwrite their toolpaths to ' button; refused parts named on the same banner; S.plasg cleared on job switch. (3) MIXED-MATERIAL GATE at the pack door: a sheet is physically ONE material, and the pack hands its plan to every referenced part -- so run_partnest now REFUSES when a listed part carries a review at a different material, naming the parts and their materials ('a sheet is one material'), instead of silently re-planning them onto the pack's pick (which is what _pl_build persist did before this gate -- the silent overwrite was live). body.material_overwrite = the explicit one-click; the blocked banner on BOTH surfaces (Part list drawer + Nest drawer) offers 'Overwrite toolpaths and pack' when the words match; the other fixes are the operator's own moves (take the rows off the list, or re-pick the material). Note a mixed list is reachable today through 'Add from existing jobs', so the gate matters regardless of upload sorting. PROVEN: NEW app/verify_plassign.js 19/19 live on dev (kitflip scratch fixtures, self-resetting baseline; covers button, skip-and-name, overwrite click, override survival, pack refusal naming parts, one-click overwrite-and-pack, zero page errors) + pltabs 24/24, partnav 15/15, plpick 17/17 green. Zero dev O-numbers consumed (packs only, no posts). FUTURE ROAD, PARKED (intent -- his 'I'm going to think more about mixing materials'): grouped per-material packing -- the Nest tab groups rows by material and packs each group as its own sheet set, one set of programs per material, all inside the one job; nothing in the data model has to change to get there. NOT commissioned; sits until Jordan rules on mixing.