# 几何编译器不施加 `road-interval` 区间

第 4 步手测时发现：区间范围手柄拖动有 ghost 反馈，但松手后几何毫无变化。
经排查这是服务端的能力缺口，不是客户端拖拽逻辑的问题。

## 事实

`grep "\.interval\b" src/compile/native-road.js` 返回空。

求解器写入了区间与过渡，几何阶段一个都不读：

| profile 字段 | solver 写入 | `compileGeometry()` 读取 |
| --- | --- | --- |
| `edgeOffsets.left/right` | ✅ | ✅ `centerlineShift`（native-road.js:825） |
| `widthMeters` | ✅ | ✅ native-road.js:832 |
| `sidewalkWidths.left/right` | ✅ | ✅ 真实宽度，`sidewalkRing`（native-road.js:1666-1671） |
| `laneDividerOffsets` | ✅ | ✅ native-road.js:1946 |
| **`interval`** | ✅ direct-edit-solver.js:274-277、418 | ❌ **零消费者** |
| **`transitions`** | ✅ direct-edit-solver.js:293、303、322 | ❌ **零消费者** |

## 后果

1. **每一次直接编辑都作用于整条路。** `anchor.startStation` / `endStation` 被存储、被
   `validateEditDocument()` 校验、被带进 `resolveDirectEditConstraints()` 的结果，然后被忽略。
2. **区间范围手柄在几何上不可能有效果。** 客户端的 `intervalRangeHandles()`、
   `projectIntervalEnd()`、`coordinateAtStation()` 都正确且有单测，但下游无人接收。
3. **`transition: 'smoothstep' | 'linear'` 是死字段。** 父任务 design.md 承诺
   「作用于 interval 两端回归基线的过渡段」，实际没有任何过渡。

## 已采取的处置

`workbench/client/src/edit/flag.ts` 增加 `intervalEditingSupported = false`，
范围手柄的 UI 据此隐藏。纯逻辑与测试全部保留。

理由：一个拖起来有反馈、松手却没效果的控件比没有这个控件更糟——它会持续产生
bug 报告，并让人怀疑整个编辑器的其余部分。区间生效的那个提交把这个常量翻成 `true` 即可，
客户端不需要其他改动。

## 对验收标准的影响

父任务 prd.md 的这条**当前无法通过**：

> 区间范围手柄可修改影响区间，两端平滑过渡回基线。

`08-26-direct-edit-map-editor/prd.md` 的同名条目同理。这不是客户端欠工，
而是需要 `compileGeometry()` 具备按 station 施加横断面 profile 的能力。

## 若要实现（未排期）

用户 2026-08-27 判断影响不大，故未开任务，仅记录。真要做时的形状：

1. `native-road.js` 的横断面生成需要接受「沿中心线变化的 profile」而非单一常量宽度。
   目前 `applyDirectEditProfiles()`（约 818-838 行）返回的是整条路一个 `widthMeters`
   和一次 `offsetLine()` 整体平移，没有沿 station 变化的余地。
2. 区间两端按 `transitions[kind]` 做 smoothstep / linear 插值回基线值。
3. 车道线、标线、connector、步行带都由横断面派生，必须一并跟随，否则会脱节
   （父任务 research/joint-solver.md 的依赖链）。
4. `test/fixtures` 基线会变化，需要显式 update-baseline 并人工核对。

这是 `compileGeometry` 的实质改动，属已归档的 `direct-edit-solver-api` 任务范围。