qs

Fixes #617. The bug With , a literal, unencoded dot inside a bracket segment corrupts the key: Without , stays a single key named . Turning on should only add dot-notation as an alternative to brackets, not change how an existing bracket segment that already contains a dot is parsed. (Independent of / .) Root cause starts with: That global regex runs over the whole raw key before the bracket-depth walk, so a dot inside is rewritten too ( → ). The fix Replace the global regex with a small helper that converts a dot to bracket notation only at bracket depth 0, leaving dots inside a bracket segment untouched. It reproduces the original behavior for depth‑0 dots, so keys without brackets are unaffected. Tests Added a test asserting that keeps as one key and matches the shape. It is committed first and fails on the current source; the full suite (1143 assertions) passes with the fix, and lint is clean. 🤖 Generated with Claude Code

Summary was applying a global replace over the entire key before the bracket walker ran. That rewrite could not tell whether a already lived inside an existing group, so keys like were turned into and then parsed as a nested key. This change only converts dots that sit outside any bracket group, matching the intended "dot notation is an alternative to brackets" semantics. Changes Add bracket-depth-aware used by Add regression tests for issue #617 (literal dots inside brackets stay literal; dots after a closed group still expand) Test plan [x] (486 pass, including new #617 cases) [ ] Existing allowDots / decodeDotInKeys cases still green in CI Fixes #617

With + , percent-encodes the structural nesting-separator dots, not just the literal dots inside a key. That breaks the documented -> round-trip for any nested object whose keys do not contain a literal dot. Repro Deeper nesting clobbers every separator except the last: The control case ( alone) round-trips correctly, so the regression is specific to . What the option means Per the README, encodes the dots that appear in the keys of an object: The dot in is part of the key and must be encoded; the dot before / is the separator inserts and must stay literal. The bug encodes both. Root cause : is the accumulated key path, so this replace runs again at every level of recursion and re-encodes separator dots that were inherited from parent levels. The literal dots inside an individual key are already handled per segment a few lines down (), so the prefix-wide replace is the source of the over-encoding. Fix Encode the dots once per key segment in the top-level driver (the same place and the same way nested child keys are already encoded), and let be the plain accumulated path. Two lines in . Relationship to #562 This is a different defect from the open #562, which fixes the opposite failure: a top-level key that contains a literal dot and has a primitive value was under-encoded ( produced instead of ). #562 never touches the line, so applying it leaves this over-encoding bug present: The two fixes share one line (moving the per-segment encode into the driver), because removing the prefix-wide replace requires the top-level key's own literal dots to be encoded there instead, otherwise the README example regresses. The distinct defect addressed here is the prefix-wide re-encoding on the recursion path. Verification Added a test for the nested separators plus a round-trip assertion; it fails on current HEAD (red) and passes with the fix (green). Full suite green: assertions pass. passes, so every documented example still produces its documented output (the literal-dot cases are unchanged). clean (no new warnings on the changed lines).