Compute the post-insert caret from node sizes, not the content array length
Source and priority
LOW follow-up from PR #1410, RoboRev combined review of 1947eb6.
Reported state
SkillEditor.tsx's insertSkill sets the caret after the inserted content with from + content.length, where content is the array of nodes it just built (the atom, plus a separator text node when one is needed). That treats the array's length as a count of document positions. It is correct today only because the atom has size one and the separator is a single space, so the array length happens to equal the inserted size in every current case.
This is a code-reading finding, not a reproduced defect — no behavior is wrong today. It matters because the equality is incidental: a multi-character separator, a second node type, or marks would silently move the caret to the wrong place, and the mistake would look like a caret regression rather than a bad offset.
Focused scope
Compute the position from the inserted nodes' sizes (or from the resulting selection) instead of the array length, and prove the caret is unchanged for every case that exists now: insertion with and without a separator, at the start, middle and end of a draft, and next to another atom.
Do not change when a separator is inserted, the ordering of insertSkill's work, or the undo grouping.
Acceptance criteria
Duplicate check (2026-09-16)
Read-only searches, including closed issues:
gh issue list --repo prime-radiant-inc/evener --state all --search '"insertSkill"' --json number,title,url,state
gh issue list --repo prime-radiant-inc/evener --state all --search '"content.length" caret' --json number,title,url,state
Both returned no issues. No duplicate found.
Compute the post-insert caret from node sizes, not the content array length
Source and priority
LOW follow-up from PR #1410, RoboRev combined review of
1947eb6.Reported state
SkillEditor.tsx'sinsertSkillsets the caret after the inserted content withfrom + content.length, wherecontentis the array of nodes it just built (the atom, plus a separator text node when one is needed). That treats the array's length as a count of document positions. It is correct today only because the atom has size one and the separator is a single space, so the array length happens to equal the inserted size in every current case.This is a code-reading finding, not a reproduced defect — no behavior is wrong today. It matters because the equality is incidental: a multi-character separator, a second node type, or marks would silently move the caret to the wrong place, and the mistake would look like a caret regression rather than a bad offset.
Focused scope
Compute the position from the inserted nodes' sizes (or from the resulting selection) instead of the array length, and prove the caret is unchanged for every case that exists now: insertion with and without a separator, at the start, middle and end of a draft, and next to another atom.
Do not change when a separator is inserted, the ordering of
insertSkill's work, or the undo grouping.Acceptance criteria
make test-webexit zero; record the tested commit and results.Duplicate check (2026-09-16)
Read-only searches, including closed issues:
Both returned no issues. No duplicate found.