docs: clean up roadmap — remove completed items, keep future work

Remove completed sections: range mappings, streaming composition,
ecosystem adoption phases 1-2 (wrapper packages shipped), resolved
Rust performance gaps (VLQ encoding, composition, structured output),
and completed extended APIs (from_data_url, browser WASM target,
ConcatBuilder, applySourceMap).

Keep: function name mappings, scopes spec alignment, sources hash,
debug ID extraction, mappings v2, env metadata, remaining ecosystem
targets.

Author: BartWaardenburg

ROADMAP.md

@@ -2,72 +2,6 @@
 
 What's next for srcmap, and why.
 
-## Range Mappings
-
-**ECMA-426 proposal, Stage 2** — [tc39/ecma426#233](https://github.com/nicolo-ribaudo/ecma-426/blob/main/proposals/range-mappings.md)
-
-A new `"rangeMappings"` field that marks certain mappings as covering an entire range, not just a single point. This directly solves precision loss during source map composition — the exact problem Rolldown hits ([rolldown#7555](https://github.com/nicolo-ribaudo/ecma-426/blob/main/proposals/range-mappings.md)).
-
-### Encoding
-
-The `rangeMappings` field uses the same `;`-separated line structure as `mappings`. Each line contains unsigned VLQs encoding **relative offsets** (1-based) to the index of each range mapping on that line. The offset is relative to the previous range mapping index on the same line.
-
-```json
-{
-  "mappings": "AAAA,CAAC,GAAG,...",
-  "rangeMappings": "ABCgB;;B"
-}
-```
-
-Decoding `ABCgB` on line 1 gives offsets `[0, 1, 2, 32, 1]`, meaning mappings at indices 0, 1, 3, 35, and 36 are range mappings.
-
-### Lookup behavior
-
-A range mapping maps every position from its generated position up to (but not including) the next mapping. The original position is computed with a delta:
-
-```
-lineDelta = lookupLine - mapping.generatedLine
-columnDelta = if lineDelta == 0 { lookupColumn - mapping.generatedColumn } else { 0 }
-result = OriginalPosition {
-    line: mapping.originalLine + lineDelta,
-    column: mapping.originalColumn + columnDelta,
-}
-```
-
-### Data model change
-
-The `Mapping` struct gains an `is_range_mapping: bool` field (default `false`). On decode, `rangeMappings` is parsed and `is_range_mapping` is set on the referenced mappings. On encode, range mappings are collected and written to `rangeMappings`.
-
-### What to implement
-
-- [x] Decode `rangeMappings` field and set `is_range_mapping` on `Mapping` structs
-- [x] Encode `rangeMappings` from `Mapping` structs with `is_range_mapping = true`
-- [x] Update `original_position_for` to apply range delta when the matched mapping is a range mapping
-- [x] Update `remap()` to preserve and compose range mappings through transform chains
-- [x] Generator API: `add_range_mapping()` for marking a mapping as a range
-- [x] WASM/NAPI bindings
-- [x] CLI: show range mappings in `srcmap info` and `srcmap mappings`
-
----
-
-## Streaming Source Map Composition
-
-**Ecosystem demand** — [rolldown#8632](https://github.com/nicolo-ribaudo/ecma-426/blob/main/proposals/range-mappings.md)
-
-Rolldown's `collapse_sourcemaps` materializes the entire token stream into `Vec<Token>` before constructing the final `SourceMap`. For large bundles with many transform plugins, this causes excessive allocations.
-
-### What to implement
-
-- [x] `MappingsIter`: lazy iterator over VLQ-encoded mappings (decodes one at a time, no `Vec<Mapping>`)
-- [x] `StreamingGenerator`: on-the-fly VLQ encoder that emits mappings in sorted order without collecting
-- [x] `remap_streaming()`: composition pipeline that streams through mappings without intermediate allocation
-- [x] Criterion benchmarks (500 / 10K / 60K mappings) — 15-20% faster than materialized `remap()`
-
-- [x] Builder pattern (`SourceMap::builder()`) that consumes iterators for names/sources/source_contents
-- [x] Bundler-scale benchmark (60K mappings across 20 sources, materialized vs streaming)
-
----
-
 ## Function Name Mappings
 
 **ECMA-426, standardized** — [bloomberg.github.io/js-blog/post/standardizing-source-maps](https://bloomberg.github.io/js-blog/post/standardizing-source-maps/)
@@ -183,8 +117,6 @@ srcmap already parses `debugId` from source map JSON. What's missing is extracti
 
 ---
 
----
-
 ## Mappings v2 Encoding `[Discussion — not implementing yet]`
 
 **ECMA-426 discussion** — [tc39/ecma426#155](https://github.com/nicolo-ribaudo/ecma-426/blob/main/proposals/range-mappings.md)
@@ -230,85 +162,15 @@ Environment metadata for source maps. The proposal is minimal at Stage 1 — tra
 
 ## Ecosystem Adoption
 
-Based on integration testing across 21 projects. Prioritized by impact and dependency chains.
-
-### Adoption Phase 1: Ship What Already Works
-
-**Commit accumulated bug fixes** found during outreach testing:
-- Path normalization (`normalizePath()`) — matches jridgewell's `resolve-uri` behavior
-- WASM source name resolution through `resolvedSources` in `originalPositionFor`
-- `generatedPositionFor` bias handling (GLB/LUB) and same-line constraint
-- `allGeneratedPositionsFor` LUB semantics and result sorting
-- Reverse index tie-breaking by generated position
-- Decoded mappings stride fix (6→7 for `is_range_mapping`)
-- `SectionedSourceMapInput` type and callable `AnyMap` type signature
-- Dual CJS/ESM exports for `@srcmap/trace-mapping`
-
-**Publish `@srcmap/trace-mapping` v0.3.0**, then open PRs:
-
-| Project | Stars | Downloads/wk | Test Results | Effort |
-|---------|-------|-------------|--------------|--------|
-| v8-to-istanbul | 220 | ~8M (via c8/Jest) | 3/3 files, all snapshots match | `package.json` swap |
-| Jest | 44k | ~30M | 0 regressions (28 pre-existing) | `package.json` swap |
-| Vitest | 14k | ~10M | 600/600 files, 6582 tests | Swap + externalize WASM in 3 Rollup configs |
+### Remaining Rust performance gaps
 
-### Adoption Phase 2: Wrapper Packages
+| Gap | Severity | Impact |
+|-----|----------|--------|
+| Serialization overhead | Medium | Rspack |
 
-Three wrapper packages unlock 10+ major projects:
+VLQ encoding and composition have been optimized. Serialization may still have room for improvement — profile against rspack-sources to verify.
 
-**`@srcmap/source-map`** — Mozilla `source-map` v0.6 synchronous API compat
-- Already prototyped and validated (source-map-support: 33/33 tests pass)
-- `SourceMapConsumer`: constructor, `originalPositionFor`, `generatedPositionFor`, `eachMapping`, `sourceContentFor`
-- Unlocks: **Next.js** (130k), **PostCSS** (29k), **Terser** (9k), **source-map-support** (3.3k)
-
-**`@srcmap/remapping`** — `@ampproject/remapping` API compat
-- Default export accepting `(input, loader)` where input is string, object, or array
-- Unlocks: **Vite** (71k), **Angular CLI** (27k), **Babel** (43k, also needs gen-mapping)
-
-**`@srcmap/gen-mapping`** — `@jridgewell/gen-mapping` API compat
-- `GenMapping` constructor, `maybeAddMapping`, `toEncodedMap`, `toDecodedMap`, `setSourceContent`
-- Unlocks: **Babel** (43k)
-
-```
-trace-mapping v0.3 ──→ Jest PR (44k⭐)
-         │              Vitest PR (14k⭐)
-         │              v8-to-istanbul PR (220⭐, 8M dl/wk)
-         │
-         ├─→ @srcmap/source-map ──→ Next.js (130k⭐)
-         │                          Terser (9k⭐)
-         │                          source-map-support (3.3k⭐)
-         │                          PostCSS (29k⭐, needs applySourceMap too)
-         │
-         ├─→ @srcmap/remapping ───→ Vite (71k⭐)
-         │                          Angular CLI (27k⭐)
-         │                          Babel (43k⭐, needs gen-mapping too)
-         │
-         └─→ @srcmap/gen-mapping ─→ Babel (43k⭐)
-```
-
-Total ecosystem reach with Phase 1+2: **~434k GitHub stars** across 10 projects.
-
-### Adoption Phase 3: Rust Performance Gaps
-
-These block adoption in Rust-native tools:
-
-| Gap | Severity | Impact | Details |
-|-----|----------|--------|---------|
-| VLQ encoding 1.8x slower | High | OXC, SWC, Lightning CSS | Profile + optimize `encode_vlq`, consider SIMD/lookup-table |
-| Serialization 2.25x slower | Medium | Rspack | Pre-allocate output buffer, avoid intermediate allocations |
-| Composition 8x slower | High | Rolldown | Missing lookup table API for O(1) line/column access |
-| No structured SourceMap output | Medium | OXC | Export `SourceMap` struct with typed fields |
-
-### Adoption Phase 4: Extended APIs
-
-| API | Effort | Unlocks |
-|-----|--------|---------|
-| `ConcatSourceMapBuilder` (Rust) | Medium | OXC (13k) |
-| `from_data_url()` / `to_data_url()` (Rust) | Small | Lightning CSS (7k) |
-| `fromSourceMap()` / `applySourceMap()` (JS) | Medium | PostCSS (29k) |
-| WASM browser target (`--target web`) | Medium | Vitest browser, all browser tools |
-
-### Adoption Phase 5: Long-Term Strategic
+### Long-term strategic targets
 
 | Target | Approach | Stars |
 |--------|----------|-------|
@@ -317,26 +179,6 @@ These block adoption in Rust-native tools:
 | Webpack | Add streaming API matching `StreamChunksOfCombinedSourceMap` pattern | 65k |
 | Metro | Low priority — needs multiple wrappers for custom source map extensions | 5.2k |
 
-### Adoption Priority Matrix
-
-| Priority | Item | Effort | Impact |
-|----------|------|--------|--------|
-| **P0** | Commit bug fixes + publish trace-mapping v0.3 | S | — |
-| **P0** | PRs to Jest, Vitest, v8-to-istanbul | S | 58k⭐, 48M dl/wk |
-| **P1** | `@srcmap/source-map` wrapper | M | 171k⭐ |
-| **P1** | `@srcmap/remapping` wrapper | M | 141k⭐ |
-| **P1** | WASM browser target | M | All browser tools |
-| **P2** | `@srcmap/gen-mapping` wrapper | M | 43k⭐ |
-| **P2** | VLQ encoding optimization | M | OXC+SWC+LightningCSS |
-| **P2** | Data URL utilities | S | Lightning CSS (7k⭐) |
-| **P3** | Serialization performance | M | Rspack (12k⭐) |
-| **P3** | Composition performance + lookup table | L | Rolldown (20k⭐) |
-| **P3** | Structured SourceMap type + ConcatBuilder | M | OXC (13k⭐) |
-| **P3** | `fromSourceMap`/`applySourceMap` | M | PostCSS (29k⭐) |
-| **P4** | Node.js benchmarks, Webpack streaming, Metro, Sentry | L | Long-term |
-
-Effort: **S** = days, **M** = 1-2 weeks, **L** = 2+ weeks
-
 ---
 
 ## Non-goals