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>
que01
7c45c21f8c