Repository navigation
docs(skills): say when the queued check of an edit runs relative to the flush - #565
Conversation
…he flush SKILL.md said that when the key comes first the schedule runs later, after the flush. A ModeChanged handler that turns the main loop runs it earlier, after visual mode ended and before the flush. The key listener has already checked the edit, so the second check finds nothing to do in both orders (the unchecked_edits == 0 guard).
|
@codex review |
|
@codex security review |
Codex Review Summary: ✅ CompletedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex Review: Didn't find any major issues. Breezy! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
🛡️ Codex Security ReviewSecurity review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
What changes
One sentence of
.agents/skills/verify-selection-tracking/SKILL.md(the bullet about edits in visual mode that the model leaves out). It said that when the key comes first, the schedule that checks the edit "runs later, after the flush". That is the usual order, but not the only one.A
ModeChangedhandler that runs before the plugin's and turns the main loop (vim.wait(0), for example) runs the queued check earlier: after Neovim ended visual mode and before the flush. The key listener has already checked the edit at the key, socheck_visual_editsfinds nothing to judge. That is theunchecked_edits == 0guard, which #540 pins with a unit test and an integration case. The second check finds nothing to do in both orders.The sentence now says both orders and why the result is the same.
Evidence
The independent verifier of #540 found the gap (round c, evidence
trail/evidence/540c). Its probek_probe.luaruns a handler that callsvim.waitinModeChanged(*:n, andv:*): with the guard (the head and mutant K), Claude holdsalphain 28 of 28 runs; without it (mutant H) in 10 of 14, and with main's code in 8 of 14.8.0 and 0.12.3. Without the guard it holds the cursor.I read the other places that describe the order (the replay headers,
lua/claudecode/README.md, the comment innote_visual_edit). The comment innote_visual_edit(selection.lua:215) says the mapping "reaches the flush before the schedule", which is the same claim; the guard keeps the result right, and a later PR corrects that comment.Gates
lua/file and no covered block changes, so no lock needs a re-record.--hash-onlymatches for all fourverify-*skills.treefmt --ci: 427 files, 0 changes.Generated with
xum• Model:anthropic:claude-sonnet-5-5• Thinking:xhigh