types/byte_set: toRangeMap carries a boolean, not an FSM payload - #1566

Approving. The narrowing is behaviour-preserving end to end, the **BREAKING CHANGES:** prefix is correctly applied, and the moved proofs still discriminate under mutation.

Baseline for everything below: origin/main at 4a3b6877 (js/keywords: one source of truth for JavaScript keywords (#1562)).

Public surface — breaking, and correctly labelled

I read the emitted declarations rather than a name-keyed extract, and diffed every .d.mts in fjs/ between the two trees after npm run prepack. The file set is identical and exactly one file differs:

fjs/types/byte_set/module.f.d.mts
- export declare const toRangeMap: (n: ByteSet) => (s: string) => RangeMap<SortedSet<string>>;
+ export declare const toRangeMap: (n: ByteSet) => RangeMap<boolean>;

fjs/fsm/module.f.d.mts is byte-identical — labelRange stays private, so the DFA layer's surface does not move.

That is a change in both arity and payload type on an exported const, so §8.4 wants the prefix and the entry has it. This is not the #1524 situation (representation-only, identical emitted surface, correctly no prefix); it is closer to #1520, where the specifier-level break did carry one. The dropped SortedSet import and its @import line go with it, and @module survives in the emitted declaration.

Behaviour sweep — no divergence anywhere in the domain

I ran main's toRangeMap(n)(s) against the PR's map(labelRange(s))(toRangeMap(n)) — importing both trees side by side in one process — over 1710 comparisons: empty, universe, all 256 singletons, ten boundary ranges ([0,0], [0,1], [0,255], [1,255], [254,255], [255,255], [127,128], …), the alternating pattern and its complement, and 300 pseudo-random 256-bit sets, each against label strings 'a', 'zz' and ''.

byte_set checked 1710 mismatches 0

Negative control: injecting one spurious entry for a single case makes it report mismatches 3 (one per label string), so the comparison is live rather than vacuously passing.

Then the same both-trees comparison one level up, on fsm's actual exports, over seven grammars — empty, id-loop, the multi-rule float/int one, a rule with the empty byte set, a rule with the universe, and singletons at bytes 0 and 255 — comparing dfa(grammar) and run(dfa)(input) for eight inputs each including '', � and ÿ:

fsm grammars 7 mismatches 0

So no divergence to classify — neither a regression nor a latent-bug fix. The old [s]/[] payload was boolean wearing a costume, and labelRange puts the costume back on at the only place that wanted it.

Proofs mutation-tested, not read (§3.2)

The four toRangeMap cases were rewritten, so I checked they still kill:

• [[prev, i]] → [[!prev, i]] (invert the payload): dies — 3 of 4 byte_set cases plus 5 fsm cases.
• current === prev ? null : [[prev, i]] → [[prev, i]] (drop the boundary check, emit all 256): dies — including the empty-set case.
• fsm's new labelRange: [inSet ? [ruleOut] : [], max] → [[ruleOut], max] (label every range, in-set or not): dies — fsm.proof.dfa and 2 run cases.

The empty-set case (assertEq(result, '[]')) is the weakest of the four on its own — it survives the inversion mutant, which is unavoidable given it produces no entries — but it is killed by the boundary mutant, so it is not dead weight.

Battery

• npx tsc --noEmit — exit 0.
• npm run prepack from a clean tree — exit 0.
• npm test — 2709 pass / 0 fail, exactly matching 4a3b6877. A behaviour-preserving change should match, and it does.
• bin/linkcheck.mjs — broken-link sets byte-identical to main. Worth checking here since the PR deletes fjs/types/byte_set/todo/torangemap-payload.md; nothing pointed at it, and the surviving mention in fjs/types/todo/bit-set-factory.md is prose about toRangeMap staying local, which is still true.
• §6.2 _ prefix: no types added. Entry joins fsm's @import list, but it is an already-public export of range_map/types.ts, so no prefix question arises. labelRange is a plain private const.
• §8.3: changelog/unreleased/1566.md is 222 characters, list items only, no heading, no PR number or link inside. Deleting a todo/ file needs no entry of its own.

The JSDoc on toRangeMap explaining why the payload is boolean and where the labelling went is the part that will save the next reader the trip through git history.