mirror of
https://github.com/pbakaus/impeccable.git
synced 2026-09-12 14:16:28 +03:00
Paul BakausandClaude Opus 4.7
99e68370b9
Cursor Bugbot caught this on PR #118 review: > JSX discard/accept restores content with wrong indentation. In the JSX > path, `indent` is captured from `lines[block.start]` — the marker comment > line inside the wrapper div, which is indented 2 extra spaces relative > to the original element. But `expandReplaceRange` expands the replacement > to include the outer `<div data-impeccable-variants>` wrapper, which sits > at the original element's indent level. `deindentContent(original, indent)` > restores content to the marker's deeper indent, so all restored lines end > up 2 spaces deeper than the original element was. I'd actually noticed the symptom during the live testing session ("some odd indentation in card-2 after discard") and dismissed it as cosmetic. Bugbot's analysis matches exactly. Fix: anchor the deindent base on `replaceRange.start` instead of `block.start`. For HTML the two are identical (markers sit outside the wrapper), so HTML is unchanged. For JSX `replaceRange.start` is the outer `<div>` at the original element's indent — correct base. Also dropped a duplicate `expandReplaceRange` call in handleAccept that the earlier edit left orphaned. Test coverage: - Two new regression tests in live-accept.test.mjs: - `discard restores JSX content at the original indent` runs the real wrap CLI and asserts the restored <aside> opener lands at its original 6-space indent (was 8 before the fix). - `accept (no carbonize, raw HTML) restores at the original indent on JSX` exercises the same anchor on the accept path. - Inner-element indent loss inside the wrapped content (`<h1>` ending up at the same indent as its parent `<aside>`) is a separate, pre-existing wrap behavior — left for a follow-up; explicitly noted in the test comments. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>