Handles for the two control-marking kinds, completing what step 1 made solvable. They drag along the approach tangent and reuse the whole existing chain — hit test, projection, clamp, ghost, debounce, arbitration, preview, save, undo — without changes to any of it. That reuse is the point of having modelled edits as kind + anchor + axis + value. Ownership: design.md gives junction reserve interiors to JunctionTools, but that rule is about junction *shape* — width, cutback, corner. Placement of the zebra and the stop line is offered nowhere else, so the main map takes it. A segment selection therefore returns its cross-section handles plus the control markings at its ends, and shape kinds stay out so the two editors never offer the same edit. The test that asserted "road kinds only" now states this rule instead. The default placements move to the solver, which owns the editable bounds and is the module a test keeps free of fs/path; native-road.js imports them rather than the reverse, so the IO-free property survives. Deliberately not done: the handle-target generalisation this task's PRD listed as step 2. These kinds persist exactly like the existing junction constraints, so there is no second write target to abstract over yet. Building the discriminator now would be designing for one hypothetical case; the signal pose work will provide the real second case. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
21 KiB
21 KiB