kerfmaster pin list · UI / workflow decisions
intentWhat we want to build. Never claimed the present, so it cannot be stale — and must never be read as a description of the code.
Content last changed 2026-08-28 — computed from the item itself, not typed.
Jordan, 2026-08-28: 'We envision that we apply versioning to all of our files. If a customer has a job with us that has 5 different features, and they want to only change one feature, we should be able to pull up the old file, change that one feature, renest if necessary, and when we later open this job for that client we should be able to see 2 versions and it should be able to go back in time an open the original versus the latest version.'
What this implies for the model:
(1) The unit is the JOB per client, and a job is an append-only chain of versions — a new version never destroys the prior one; both stay openable side by side ('the original versus the latest').
(2) A version is the FULL job state, not just the input file: source geometry, per-feature tooling with every operator override (the per-contour slot), the nest, and the posted NC — so opening version 1 shows the job exactly as it was delivered then.
(3) Edit-in-place inheritance: version N+1 starts as version N — change the one feature the customer asked about, keep the other features' tooling/overrides intact, renest only if necessary. This is the versioned form of the nest↔tooling loop, and identical-feature propagation applies within the new version.
What we already have that maps onto it: the comparison-board build directory is exactly this shape today — immutable numbered builds, supersessions recorded, old builds still openable (build 143 nominal vs 145 mid-band both live). The intent formalizes that per CUSTOMER JOB with a proper open-old-vs-new view. The project repo itself is git-versioned, so the storage primitive exists; the design work is the job-level identity (what groups versions into one job) and the version-creation trigger.
ANSWERED (Jordan, 2026-08-28) — 'Envision GitHub as a model.' (1) Version-creation trigger: YES — every posted delivery is automatically a version; scratch work in between is not. (3) Revs: 'We have internal and external Rev's we have to deal with. For our internal we have to be able to go back in time, based on what we produced.' So the INTERNAL chain is keyed to what we PRODUCED (deliveries — like commits), and the customer's EXTERNAL print rev is a label attached to whichever internal version(s) implemented it (like a tag on a commit; several internal versions — a renest, a tab tweak — can serve one customer rev). Going back in time walks the internal chain; conversation with the customer happens in their rev labels.
(2) Deprecation — RULED (proposed by us, agreed by Jordan, 2026-08-28: 'Agreed.'): a delivered version is IMMUTABLE forever, like a commit — its bytes never change and it is never deleted; 'what we produced' stays exactly reopenable. Deprecation is METADATA ON a version, never modification of it. Two distinct states: superseded (the normal case — v2 replaces v1, v1 remains honest history, opens with a 'superseded by v2' notice) and deprecated / do-not-cut (a version found DEFECTIVE — wrong hole size, bad rev — stays openable for the record but carries the mark, the reason, who set it and when). Opening or re-posting a do-not-cut version raises a RED warning through gcode-warning-callouts — warn, never block, and if posted anyway the NC carries the (warning) comments. Default open = latest delivered version; older versions open explicitly.
Phase rule: record the intent; the version-browser UI is not built. Build rule honored everywhere: data in JSON, generator separate from presentation, so builds/jobs stay diffable and re-openable.
New surface (2026-08-28, nesting walkthrough step 2 — pin nest-name-prog-number): the nest NAME is where versioning meets the operator's eye. Jordan: 'We may want to append the date, and think about how you'll want to solve versioning for this.' Our proposal (stated, awaiting correction): the name stays the human label; the version identity lives in this pin's internal chain; the display auto-suffixes date + internal version at each delivery.