lsp: count definition rebinds separately from confirmations - #613
Merged
Conversation
The definition fallback's rebind arm rewrites an edge's target and tags rebound_from, then counted the correction into edges_confirmed. Split it into EnrichResult/EnrichmentStatus EdgesRebound and surface it beside the existing counters (enrichment logs, index_health sums, zero-yield guard).
On a degraded pass the serial fallback loop can be the only source of progress - every other usefulYield site is unreachable - so the productivity checkpoint read a pass that settles thousands of edges there as zero-yield and cancelled it.
zzet
approved these changes
Aug 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The definition fallback has two outcomes and one counter. When the server's answer agrees with the heuristic target, the edge is confirmed; when it lands on a different same-name declaration, the edge is rewritten — target replaced,
rebound_fromtagged — and then counted intoedges_confirmedall the same. A pass that "confirmed" an edge by replacing its target didn't confirm anything: it corrected the graph. The result surface,index_health, and the logs can't tell the two apart — while the same logs carry arefutedfield that nothing currently increments.This is №5 from the #605 discussion — the measuring-instrument piece. The dispatch-predicate work that follows will concentrate LSP attention exactly where the AST's answer is least trustworthy, so corrections have to be visible before it lands or its accuracy effect is unmeasurable.
Change
EnrichResult.EdgesRebound/EnrichmentStatus.EdgesRebound(edges_rebound): the rebind arm of the definition fallback increments this instead ofEdgesConfirmed, soedges_confirmedonly ever means "the heuristic target was right".refuted), the LSP degraded / deadline-cut logs, andindex_health's landed sum +lsp_resolved_edges_by_language.EdgesRefutedstays as-is; wiringRefuteEdge/refute_unconfirmedis a separate conversation.What it shows on a real graph
My workspace's settled store carries 4 rebound edges today, all textbook same-name corrections — e.g. in this repo's own eval tree, the call in
eval/run_eval.py::process_instanceoriginally bound toeval/prompts.py::render_instance_promptwas rebound toeval/agents/gortex_agent.py::GortexAgent.render_instance_prompt. Rare for now; the predicate work aims the fallback at precisely the sites where these live, and this counter is how we'll see what it changes.Tests
Two pins drive the real passes through the package's instrumented fake server: a definition answer landing on a different same-name declaration counts as
edges_reboundand must not inflateedges_confirmed; an agreeing answer still counts as confirmed. Full suite matches my Windows baseline.