kerfmaster pin list · UI / workflow decisions
rulingA decision by Aristide or Jordan. True because it was decided; it can be superseded, but it cannot be stale.
Content last changed 2026-09-06 — computed from the item itself, not typed.
RULING (Jordan, 2026-09-06): the numbered-box sequence on the Nest tab and the posted program are ONE order, always -- zero tolerance, no 'the drawer explains the difference' exceptions. Born on O33339: the macro program's second G65P9997 array ran its stood column bottom-up while the boxes showed 37 starting at the top-left of the second grid.
BUILT same day (record): server._seq_arrays replaces _lattice_arrays -- the macro decomposition WALKS the displayed order (nest_rules.serpentine_order with the saved corner/alternation/axis options, the very list the boxes render): maximal uniform columns become K-blocks whose origin is the column's FIRST displayed part (a top-start column posts J NEGATIVE -- Jordan confirmed the control accepts it); matching consecutive columns merge into one KxQ block (so 'every column from the corner' keeps the shortest form); anything that doesn't chain is its own K1Q1 block (the ruled lone-part form). Every layout is therefore macro-representable in the exact displayed order -- the old irregular-falls-part-by-part fallback is gone (test_nestedit 25 updated). A separate-arithmetic re-audit inside the decomposition expands the blocks and refuses any order mismatch before a file exists; the audit's expand_p9997 already handled signed pitches, so the posted-file gate judges the same order the machine runs. postnest.json now records part_order + part_order_source in macro mode too (no more None); mode_why says 'executing the displayed order exactly'; the Nest drawer note says the numbers ARE the cut order in either style. A clicked custom order still posts part-by-part per the 2026-08-28 two-shapes ruling -- which also follows the boxes literally. Proven: test_seqexact.py 15 NEW controls (independent expansion of the posted bytes lands on the ordered placements; signed-J top-start column; KxQ merge both ways; off-lattice K1Q1; two orientations across subs; clicked fallback; number kept).
SERPENTINE TRAVERSAL RULED + BUILT (Jordan, 2026-09-06, same thread): asked whether one P9997 could carry his two opposite-direction stood columns, Jordan stated the machine fact verbatim: 'P9996 (X) and P9997 (Y) both serpentine. You can start in the positive extreme and subtract, or start in the negative extreme and add, Mitsubishi doesn't care.' A KxQ array therefore runs DOWN the first column and back UP the second -- odd columns reversed -- which replaces the raster assumption nc_audit.expand_p9997's docstring had flagged as undocumented. Built in one commit: expand_p9997 expands odd columns reversed (the audit judges the machine's REAL order); server._seq_arrays merges consecutive columns into one KxQ ONLY when they chain as the serpentine (opposite direction, next column starting on the row the previous ended, uniform X step; single-part columns chain on Y alone) and its separate-arithmetic re-audit walks the same serpentine. Consequence, and the shortest-GCode objective satisfied: the DEFAULT alternating serpentine display now merges to ONE KxQ block per uniform region (Jordan's own estimation -- one macro starting top-left, down column 1, up column 2), while alternation-off (every column same direction) posts one signed-J block per column -- same-direction columns can never be one KxQ, the machine would snake them. The pre-fix merge rule (same-direction columns into KxQ) was itself wrong against the real control and is retired. Proven: test_seqexact 15 -> 16 controls (controls 7/8/9 flipped to machine truth, 9b = Jordan's exact top-left form); nc_warn 23 / nestedit 38 / progstyle 24 / seqcorner 17 / nestseq 27 / tooling_doc / rules 14 / drag 23 / sketch 21 green.