Step 1 of the control-marking task, and deliberately server-only: no handle is
drawn yet. This project already shipped a range handle for `profile.interval`,
which compileGeometry ignores, so the control dragged and changed nothing. The
consumer comes first now.
Two kinds join the taxonomy — `junction-crosswalk-inset` and
`junction-stop-line-offset`, both on the existing `junction-approach` anchor. The
solver writes them onto the approach entry, `applyDirectJunctionPlans` carries
them onto the compiled approach, and `compileControlMarkings` reads them in place
of the module constants it used for every junction. They move markings without
reshaping the junction, so unlike width and cutback they deliberately do not
trigger a boundary recompute.
`applyJunctionConstraint` becomes an explicit switch. Its trailing `else` had
meant every kind that was not approach-width fell through to the cutback
validator, so a new kind would have been silently validated and written as a
cutback. The same non-exhaustive shape in the test fixture's `valueFor` is fixed
the same way, and now throws for an unnamed kind rather than answering with a
corner radius.
design.md's taxonomy is updated with it — a test asserts the two cannot drift,
which is what caught the omission.
Measured on a 41-road workspace with 8 crossings: both constraints change their
marking geometry, neither drags the other, and out-of-range blocks instead of
clamping. That measurement is not in the suite: the synthetic junction resolves
`junction_inset_m` to 0 because its crossing never binds to a plan, and the
committed OSM fixture has no crossings at all. The tests assert the wiring the
handles will depend on — values reaching the approach entry, distinct branches,
blocking diagnostics — and the gap is recorded in the test itself.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Three things, kept in one commit because they touch overlapping hunks of the
same two files and this environment has no interactive hunk staging. Splitting
them by file would have drawn boundaries that misrepresent what changed.
1. Step 4 of the map editor. A native OpenLayers PointerInteraction turns a
drag into a clamped constraint value, the ghost source shows it immediately,
and the solver's answer replaces a parallel set of preview layers while the
baseline layers are hidden rather than overwritten. Preview requests debounce
at 80 ms, pointerup flushes without waiting, and a newer request aborts the
one in flight; EditSession decides which answers count. Handle positions come
from the clamped value, so a handle stops at its limit instead of following
the cursor. Three of the four drag capabilities are live: edge offset,
sidewalk width, lane divider.
2. Road edge handles were drawn on the wrong side. offsetLine() offsets
counter-clockwise from the direction of travel and sidewalks use
`heading + (side === 'left' ? -90 : 90)`, so left is `tangent - 90`;
makeRoadHandles() placed the left handle at `tangent + 90`, over the right
kerb. Dragging the visually-left handle moved the right edge. Fixed on both
sides of the wire, with regression tests that name the sides geographically
rather than by axis sign.
3. Roads the junctions geometrically fill are now read-only. The 0.45 cap per
reserve made the existing `unavailable` branch unreachable, so a 14.5 m stub
between two junctions was offered a 1.5 m editable band with no room for the
transitions a road-interval constraint needs. Greying only affects the
manifest: constraints already saved against such a road keep being solved, so
the geometry output is unchanged and the fixture baselines do not move.
Range handles are built and unit-tested but hidden behind
`intervalEditingSupported`: compileGeometry() reads neither profile.interval nor
profile.transitions, so every edit applies to the whole road and the control
would have had no effect. Recorded in research/interval-not-applied.md, which
also blocks one PRD acceptance criterion.
The ol-ext probe stays in the tree as a manual harness; ol-ext is still not a
dependency.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Planning: parent design.md becomes the single authoritative contract
(constraint model with 6 kinds, handle manifest, coordinate/unit
layering, preview sequencing, storage layout and lazy migration, area
config snapshot, API contract). Work is split into four independently
verifiable child tasks with per-step gates and rollback points.
Test infra: pin vitest 4.1.11, add test:client:unit for client pure
logic, extend prettier globs to root *.ts so vitest.config.ts is checked.
Add .gitignore: the repo had none, so inputs/, outputs/, workbench-data/
and the client build output were untracked rather than ignored.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
