1753 commits

This branch

This branch

All branches

Author	SHA1	Message	Date
Gergő Magyar	56fc7936d2	Merge branch 'main' into fix/skill-evolution-gate	2026-08-01 22:42:41 +01:00
Gergő Magyar	911151e230	fix(resolution): resolve Go pointer-receiver calls, and report the program boundary instead of hedging (#2766) (#2782)	2026-08-01 22:42:18 +01:00
Gergo Magyar	b5bcdb6c48	fix(eval): redact the token from the one failure line that now reaches CI ... `ManagedProcessError.__str__` embeds up to 1000 raw bytes of stderr_tail (process_control.py:72-73), and run_cell printed it verbatim. That line was inert until this branch: nothing ever printed the sweep subprocess's stdout, on success or failure. `echo_stdout` streams it live into the job log, so the print became a sink — and the only one of its kind here that skipped `redact_text`, which results.jsonl and every transcript already apply to exactly this field, for exactly this reason. GitHub masks the registered secret, but masking only catches that literal value; it is not the guarantee the other sinks have. The test drives a ManagedProcessError carrying the token in stderr_tail and asserts it never reaches stdout — verified to fail without the fix. Also from the same pass: bind `result_indexes[0]` once in run_claude, and give the workflow contract test a `findStep` helper instead of five copies of the same `steps.find` predicate.	2026-08-01 20:11:00 +00:00
Karl Lehenbauer	639eb04b31	fix(swift): preprocess indented conditional directives so class bodies survive parsing (#2771) ... * fix(swift): preprocess indented conditional directives so class bodies survive parsing * fix(swift): make conditional-directive blanking comment-, string- and brace-aware (#2771) Addresses the review findings on PR #2771. The transform fired unconditionally, which turned valid Swift into parse errors while missing the most common shape it was written for. - The blank/keep decision now consults `blockCommentDepth`, so ` #endif */` — the result of commenting out a conditional block — keeps its comment terminator. Previously `hasError` went raw=false -> preprocessed=true and the rest of the file was swallowed. - The decision keys on the scanner's brace depth instead of indentation. A column-0 `#if` inside a class body is blanked (6 of 7 body shapes previously still lost the enclosing declaration) and an indented file-scope directive is not — matching what the doc comment already claimed. Bare-CR line endings, NBSP/ideographic indentation and a leading BOM are recognized too. - A group is blanked only when every branch is brace-balanced. An `#if`/`#else` that splits a declaration header leaves one unmatched `{` once both branches survive, which collapsed five top-level nodes into one and gave unrelated types fabricated `NetworkClient.` qualified names. Such a group now degrades to the pre-fix behavior. - Multiline strings honour `\"""` escapes, and a plain `"""` closes even when a `#` follows it, so the scanner no longer wedges in string state and silently stops blanking for the rest of the file. - The pound run is counted once per position and skipped. It was quadratic: 10.6s for one 64k-`#` line, well inside the 512 KB walker limit. - Extended regex literals (`#/.../#`) no longer open a phantom block comment. - Directive-free files return early, matching `stripUeMacros`. Worker parity: `emitSwiftScopeCaptures` and `emitCppScopeCaptures` re-apply their provider's `preprocessSource` on the parse-cache-miss path — Dart already did this — and the embedding parse in `ensureAndParse` applies the hook as well. Before this the worker and the scope-capture/embedding halves analyzed different programs, turning a consistent degradation into cold-run/warm-run non-determinism. A new parity test pins the equivalence for every provider that defines the hook. SCHEMA_BUMP 37 -> 38: this changes parse semantics, the chunk key hashes raw on-disk bytes, and `preprocessSource` runs after the key is computed — so a same-package-version warm cache would replay pre-fix Swift results verbatim, including across `--force`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * refactor(ingestion): apply preprocessSource once in the scope bridge (#2771) Follow-up cleanup on the review fixes. The previous commit re-applied each provider's `preprocessSource` inside `emitSwiftScopeCaptures` and `emitCppScopeCaptures`, mirroring what Dart already did — three copies of the same rule, and a contract that asked every future emitter to remember it. `extractParsedFile` is the single funnel every `emitScopeCaptures` caller passes through (parse worker, scope-resolution run, Vue script extraction), and it already receives the provider. Applying the hook there on the cache-miss path covers all three languages and every future one, names no language in shared code, and drops Dart's unconditional transform on the cache-hit path. Verified the three emitters use `sourceText` for nothing but the parse, so the substitution is output-identical — which the parity test asserts directly. Also from the cleanup pass: - the parity test derives its language list from the provider registry, so a new provider adopting the hook fails until it adds a fixture - `ensureAndParse` resolves the provider from the language it already computed, instead of a second extension table (`getProviderForFile`) - the preprocessor returns `sourceText` unchanged when no group was blanked, which is the common case for files whose only directives are top-level - `split(/(\r\n|\n|\r)/)` replaces the hand-rolled line splitter, and the per-group brace bookkeeping is two scalars instead of an array - the hint regex is derived from the line regex so the two cannot drift - unit assertions compare the WHOLE preprocessed file against the expected blanking, replacing per-line spot checks; the pipeline tests share one `runFixture` helper and `getNodesForFile` in the resolver test helpers - `LanguageProvider.preprocessSource` documents the real call sites and says plainly that the set is not closed — `populateRangeBindings` still hands language helpers raw text Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * chore(autofix): apply prettier + eslint fixes via /autofix command --------- Co-authored-by: Gergő Magyar <gergomagyar@icloud.com> Co-authored-by: Gergo Magyar <gergomagyar0@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>	2026-08-01 20:10:58 +00:00
Gergo Magyar	8076b98fcc	refactor(ci): address the evidence path directly instead of threading it ... The upload step needs a path that does not depend on the sweep step surviving. It did not need shared state to get one: `runner.temp` is available in a step, only not in a job-level `env:`, so each of the three consumers can name `${RUNNER_TEMP}/wfevolve` itself. That deletes the env var and the step that published it — the previous fix swapped one threading channel for a sturdier one where no channel was required. Also from the same review pass: - `announce`/`keep` drop their default-argument capture of `task["id"]` and `per_arm`. Late binding only bites a closure invoked after the loop moves on; these are called synchronously inside `sweep_task_cells`, which blocks until every wave completes. The trick was guarding against a race that cannot happen here, while implying to the next reader that it can. - `_stub_cell_dependencies` returns the list its teardown appends to rather than taking it as an out-parameter, dropping the boilerplate from every call site. - The workflow's `WORKERS` comment points at the `--workers` help text instead of restating it, so the rationale has one home.	2026-08-01 19:34:57 +00:00
azizur100389	d268f351d3	fix(group): preserve manifest-only impact crossings (#2784) ... * fix(group): preserve manifest-only impact crossings Keep proven manifest cross-repo hits when the far endpoint has no concrete graph symbol, avoiding a guaranteed failed UID fan-out. * fix(group): verify manifest-only neighbor repos Keep manifest-only crossings from bypassing neighbor repository resolution so unavailable repos still surface as truncated fan-out. * fix(group): distinguish boundary-only impact crossings Keep manifest-only boundaries visible without treating unattempted fan-out as completed impact or escalating risk, and cover service scope, deduplication, and real bridge persistence. --------- Co-authored-by: Gergő Magyar <gergomagyar@icloud.com>	2026-08-01 20:24:06 +01:00
Gergo Magyar	d18dbd4143	fix(ci): publish the evidence path from a step, not a job-level env ... `${{ runner.temp }}` does not exist in a job-level `env:` block — the runner context is only available to steps — so OUT_ROOT would have resolved to a bare `/wfevolve` at the filesystem root. The sweep would have failed writing there, and the upload would have pointed at nothing. actionlint caught it; this repo lints workflows for exactly this reason. The property that mattered is kept: the path is fixed before anything can fail, rather than read from the sweep step's outputs — that being the step whose death is the reason the upload matters. The first step now publishes it to GITHUB_ENV, which every later step sees, including the `if: always()` upload after a killed sweep. The contract test pins the step's position and its exact line, so the context cannot creep back into the job block.	2026-08-01 18:53:51 +00:00
Gergő Magyar	c05c56ffc9	Merge branch 'main' into fix/skill-evolution-gate	2026-08-01 19:50:33 +01:00
Gergo Magyar	edb24da1e8	feat(ci): expose benchmark cell concurrency to the evolution lane ... `--workers` reaches the sweep from evolve.py and from a workflow_dispatch input. Both default to 1, so nothing about the scheduled lane changes: the runner is sized for one cell at a time, and a cell starved of CPU drifts toward its session timeout, which the gate counts as an excluded run and refuses to decide on. generation_timeout_seconds is left alone deliberately — it is a worst-case sum-of-every-timeout bound (843h at current settings), already far looser than any real run, and concurrency only makes it looser. Raising the input is gated on the runner resize; the contract test pins the default so the lane cannot start running 3-way on a 2-vCPU box by accident.	2026-08-01 18:48:19 +00:00
Gergo Magyar	63d29c384f	feat(eval): run a task's benchmark cells in waves instead of one at a time ... 18 cells at ~48 min each, strictly serial, is 97.4% of a generation's 14.7h. The cells are independent — the wall clock was a scheduling choice, not a measurement requirement. `--workers` (default 1) runs the cells of one task concurrently; tasks stay sequential, so the sanitized graph snapshot each task already builds before its cells stays a single-writer affair. Threads, not processes: cells are subprocess-bound and `run_managed` keeps every piece of ownership state local to its own call, so nothing is shared to race on. Waves, not one fan-out. The outage breaker counts CONSECUTIVE systemic failures, and "consecutive" means nothing in completion order — folding as futures landed would make the trip point flaky between identical runs. Each wave is folded in submission order once complete, and the next wave starts only if the breaker held, so the breaker overruns by at most `workers - 1` cells (the ones already in flight) rather than by a whole task. `--workers 1` calls the cell directly rather than using a pool of one. That is not an optimisation: an async KeyboardInterrupt is delivered only to the main thread, so a cell on a worker thread is outside the reach of the ownership cleanup that kills its sandboxed process tree. The default therefore stays exactly what it is today, Ctrl-C included, and above 1 the flag's help says what is given up. All bookkeeping stays on the main thread — the results.jsonl append, the per-arm accumulation, the progress prints, the streak fold. No lock is needed anywhere, the progress counter cannot race, prints do not interleave, and results.jsonl keeps its canonical order. Every future is read. An exception a cell did not expect stays parked inside its Future until something asks for it; unread, a harness bug would become a silently missing run instead of a crash.	2026-08-01 18:48:19 +00:00
Gergo Magyar	b30f530698	refactor(eval): make a benchmark cell a callable instead of loop-body scope ... The sweep's innermost body — clone, sandbox, sessions, verify, oracle, teardown — was ~260 lines of `main()`'s scope, reachable only by running the whole sweep. Nothing tested it, and it could not run anywhere except that loop. `run_cell(ctx, run_idx, arm)` now owns one (run, arm) cell and returns its row; `TaskCellContext` is a frozen dataclass holding the per-task inputs a cell reads, so a cell depends on named fields rather than on whatever `main()` happens to have in scope. The try/except/finally moves verbatim, exception whitelist unchanged: a harness bug still escapes rather than being recorded as an ordinary infra-error and averaged into the evidence. The task asset snapshot is now prepared once per task, next to the graph snapshot, instead of lazily inside whichever cell reached it first. `TaskAssetCache` is a plain dict (task_assets.py:222-226,340), so the lazy build was a read-then-write race waiting for a caller that is not strictly serial. One behavior delta: when that preparation fails, every cell of the task now reports the same wrapped RuntimeError, where before the first cell reported the original OSError/SandboxError/ValueError. The loop keeps all the bookkeeping — progress counter, prints, the results.jsonl append, per-arm accumulation, the outage streak. Behavior is otherwise unchanged; this is the seam, not the concurrency. Six new tests cover it, the first coverage this body has ever had: the row's task/arm/run/digest bindings, each of the five expected failure kinds still removing the clone, an unexpected KeyError escaping while cleanup still runs, cleanup failure overriding the primary outcome, and a failed per-task snapshot failing every cell closed.	2026-08-01 18:48:18 +00:00
dependabot[bot]	a6aae8142d	chore(deps)(deps): bump brace-expansion from 5.0.7 to 5.0.9 in /gitnexus (#2786) ... Bumps [brace-expansion](https://github.com/juliangruber/brace-expansion) from 5.0.7 to 5.0.9. - [Release notes](https://github.com/juliangruber/brace-expansion/releases) - [Commits](https://github.com/juliangruber/brace-expansion/compare/v5.0.7...v5.0.9) --- updated-dependencies: - dependency-name: brace-expansion dependency-version: 5.0.9 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>	2026-08-01 18:00:21 +00:00
Gergő Magyar	48a03464de	Merge branch 'main' into fix/skill-evolution-gate	2026-08-01 18:44:36 +01:00
Gergo Magyar	01be282667	fix(ci): make the evolution lane survive its own deadlines and remember prior runs ... An end-to-end pass over the lane — instance start, job, artifacts, promotion — found three ways it loses work that has already been paid for. **Evidence died with the job.** Three budgets have to nest: EventBridge keeps the box up 24h from ~02:45, the job timeout was also 1440min, and the sweep had no budget of its own. A job-level timeout CANCELS the job, so the upload step never runs; and since the box stops 24h after it starts while a scheduled run can begin well after the cron (the 2026-08-01 run was queued 65min late), the box always won that race — the runner would simply vanish mid-step. The job now gets 21h, the sweep step 19h, so a wedged generation fails the step, keeps the job alive, and still uploads. The nesting is asserted in the contract test. **The upload could be skipped.** Its path came from an output the sweep step wrote — the same step whose death is the reason the upload matters. OUT_ROOT is now a job-level env constant known before anything runs, and the upload is unconditional: results.jsonl and transcripts are appended as the sweep goes, so a killed generation still holds the evidence that explains why it died. **The lane was memoryless.** `--seed-results` is how a run sees what already lost (summarize_gate feeds the prior promotion.json to the proposer), and with the default --generations 1 there is no earlier generation in-process to supply it — the workflow never passed it, so every Saturday proposed from a blank slate and could re-propose the same rejected candidate forever. The lane now seeds from the last successful run's artifact, best-effort: a first run, an expired artifact, a missing gh, or a failed download proceeds without it rather than costing a generation. Also guards the silent-promotion path: `.claude/skills/*` is gitignored with a hand-maintained per-skill allowlist, and `git status --porcelain` — how the workflow detects an applied promotion — is blind to ignored paths. A candidate skill missing from that allowlist would report "No promotion this run" after the gate said promote. A test now asserts every CANDIDATE_SKILLS entry is visible in all three shipped trees.	2026-08-01 17:42:48 +00:00
ivangegovdve-sudo	565287528d	fix(ci): stop CI Report dying silently when the tests job fails (#2728) ... * fix(ci): stop CI Report dying silently when the tests job fails The "Build report" step in ci-report.yml runs under `bash --noprofile --norc -e -o pipefail`. It located its inputs with UNIT_SUMMARY=$(find "$DIR/test-reports" -name ... 2>/dev/null | head -1) `coverage-merge` in ci-tests.yml is `needs: tests` with no `if: always()`, so any failing shard skips it and the `test-reports` artifact is never uploaded. `find` then runs against a directory that does not exist and exits 1; `-o pipefail` carries that status through `| head -1`, the command substitution hands it to the assignment, and `-e` kills the step. The death is invisible: `2>/dev/null` discards find's error and the whole report is built into `$GITHUB_OUTPUT`, so the step logs nothing and just reports "Process completed with exit code 1". "Comment on PR" is then skipped, so the CI Report workflow fails and posts nothing on exactly the PRs whose tests failed — when the report is most useful. The "Coverage data unavailable" fallback already existed for this case but was unreachable, because the script died ~160 lines before it. Route the four lookups through a `find_first` helper that returns empty when the root is absent. Verified by extracting the step body and running it against both artifact layouts: with `test-reports` present the output is byte-identical to the previous script (1335 bytes), and with it absent the step now exits 0 and emits the coverage-unavailable report instead of exiting 1 with an empty $GITHUB_OUTPUT. Observed on 32 of the last 100 failed runs; correlation with the tests job's conclusion was 6/6 failure and 4/4 success in the sampled runs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ci): let the prebuild assertion report a missing .node `Build prebuild` deletes `$pkgdir/prebuilds` before running prebuildify, so a run that emits nothing without failing leaves `find` searching a path that no longer exists. Under the step's `shell: bash` (`-e -o pipefail`) that `find` exits 1 and kills the step before the `test -n "$out"` guard below it — the guard written to explain exactly this case never runs, and the job dies with a bare "Process completed with exit code 1". Same shape as the `ci-report.yml` fix in this PR: a lookup that exits non-zero on an absent root pre-empts the fallback beneath it. `|| true` hands the empty result to the guard, which still fails the build, now with `::error::prebuildify produced no .node`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Gergő Magyar <gergomagyar@icloud.com> Co-authored-by: Gergo Magyar <gergomagyar0@gmail.com>	2026-08-01 18:31:49 +01:00
Gergo Magyar	5f51c9ed80	refactor(eval): fold the review cleanups into the evolution fixes ... - `_na` moves next to `measured_cost` in runner_sessions, the function whose None it renders, so the proposer-progress line stops reimplementing it inline. - `evaluate_candidate` derives `ungated_tasks` from the `gated` flag already on each row instead of accumulating a parallel list, and reports the carve-out as one aggregate line rather than one per task: `reasons` is truncated to three entries when it is fed back to the proposer (summarize_gate), and a growing set of unsolvable tasks must not crowd out why the candidate actually won or lost. - run_claude cuts the event window at the result event, so "nothing after the result is evidence" is a property of what the readers below can see rather than an assumption that a `system` event never carries a tool_use block. - The teardown test builds its stream with the existing `event_stream` fixture instead of re-joining the prefix by hand.	2026-08-01 17:18:43 +00:00
Gergo Magyar	2c399a0039	fix(eval): stop letting a task neither arm can solve veto every promotion ... The gate demanded that the candidate resolve every valid run of every selected task, regardless of how the incumbent scored. inv-feature-list- repos-filter fails its hidden oracle on 100% of runs in both arms, so the quality floor could never be met while it stayed in the set — and its cost comparison (which ranks who spent more while failing the same oracle) also fed the per-task regression cap and the median. One task outside both arms' capability was silently vetoing every future promotion. A task both arms measured cleanly — at least min_runs valid runs, zero exclusions — and that neither ever resolved carries no signal about the candidate. It is now reported in the decision (`gated: false`, plus an `ungated_tasks` list and a named reason) and left out of the floor, the regression cap, and the median. It still runs, and its failures still feed the proposer as evidence: an unsolved task is the loop's target, not its veto. The floor is unchanged everywhere it has signal. A candidate that goes 2/3 where the incumbent goes 1/3 is still rejected as unreliable, and a generation where NO task resolved anywhere is now `insufficient_evidence` rather than an efficiency verdict over runs that all failed. promotion.json goes to schema_version 4 — task rows changed meaning, and a stale v3 binding must not be applied under the new rule.	2026-08-01 17:07:14 +00:00
Gergo Magyar	5a017f2722	feat(eval): report evolution progress while the generation is still running ... Run 29907431284 printed its whole 14h45m of output at one timestamp (00:02:59.32) as the process exited: stdout is a pipe, so CPython block-buffered it, and there was no way to tell a live run from a wedged one. Three changes make the lane observable in the Actions log: - PYTHONUNBUFFERED for the driver (workflow step) and for the benchmark subprocess (its env is an explicit minimal dict and inherits nothing), so lines reach the log when they are written. - run_managed grows `echo_stdout`, a passthrough that streams a child's stdout to stderr as it arrives while leaving the bounded tail intact. evolve.py enables it for the benchmark sweep — the multi-hour phase, whose per-run lines previously surfaced only as a tail, and only on failure. It stays off everywhere else: a Claude session's stdout is the evidence stream and is written out only after redaction. - The sweep now announces each cell as it starts (`3/18, 47m elapsed`) and reports `took=` and `error_kind=` when it finishes, so an excluded run — the thing that actually blocks promotion — is visible live instead of only in results.jsonl. evolve.py also reports the proposer's duration, turns, and cost once the proposal lands.	2026-08-01 17:01:03 +00:00
Gergő Magyar	e1df209367	Merge branch 'main' into fix/skill-evolution-gate	2026-08-01 17:54:38 +01:00
Gergo Magyar	bb09ce28e0	fix(eval): stop discarding completed benchmark sessions as unverifiable ... The evolution loop has not been able to promote anything since it went online. Run 29907431284 (the last green run) reached the gate and threw away 5 of its 18 runs, and the gate requires zero excluded runs in both paired arms — so the generation could never produce a verdict on merit. Two causes, both in the session layer: 1. Claude Code drains background-task bookkeeping after the final result event (`background_tasks_changed`, `task_updated`, `task_notification`, all `type: "system"`). The parent-stream check required the result to be the literal last event, so three sessions that had exited 0 with a complete result and usage payload were recorded as session errors. Trailing `system` events carry no tool_use/tool_result/usage payload and cannot forge skill or cost evidence; anything else after the result still fails closed. 2. The 3600s per-session ceiling killed two `workflow` incumbent runs on inv-bug-pdg-note mid-verification. Successful `workflow` rows in the same run finished in ~1600-2600s across both sessions, so the ceiling moves to 5400s and now lives in one shared constant instead of two argparse defaults that could drift apart. Also marks the activation checklist against reality: the secrets, the Environment, the runner, and the validation dispatch are all in place; the repository variable GITNEXUS_EVOLUTION_ENABLED is the one remaining gap, and until it is set the Saturday cron skips the job in seconds while the EventBridge schedule still starts the runner for the day.	2026-08-01 16:45:48 +00:00
MyShining	1147646518	feat(spring): model AOP transactions, caching, and security (#2783) ... * feat(spring): model AOP advice and proxy behavior * fix(spring): address AOP review findings --------- Co-authored-by: Shining <xuenning@qiyi.com>	2026-08-01 17:22:12 +01:00
ChunxueLi	99291891b7	feat: make MAX_CALLABLE_VALUE_TARGETS configurable via env (#2725) ... * feat(scope-resolution): make MAX_CALLABLE_VALUE_TARGETS configurable via env The branch's original commit was a whole-file snapshot taken at a stale base and never touched the constant, so the env read was missing and the branch's own test failed. Implemented here, matching the sibling GITNEXUS_MAX_PROPERTY_DISPATCH_FANOUT knob. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(callable-value-flow): add env override tests * docs(callable-value-flow): document GITNEXUS_MAX_CALLABLE_VALUE_TARGETS env Adds a Troubleshooting subsection to README.md and a commented entry to gitnexus/.env.example for the new per-callable-site dispatch-target cap (default 32), following the maintainer's review request to document the knob alongside its implementation. --------- Co-authored-by: Gergo Magyar <gergomagyar0@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Ubuntu <ubuntu@localhost.localdomain> Co-authored-by: Gergő Magyar <gergomagyar@icloud.com>	2026-08-01 12:42:36 +01:00
Karl Lehenbauer	bebb1d2367	fix(schema): declare Swift member-containment pairs in CONTAINS DDL (#2769) ... * fix(schema): declare Swift member-containment pairs in CONTAINS DDL * fix(schema): declare remaining Rust impl/trait and JS/TS object-literal HAS_METHOD pairs; guard streamed emit sinks against undeclared pairs (PR #2769 review) * refactor(schema): share one declared-pairs constant across router and sinks DECLARED_REL_PAIRS was being computed independently in three places (csv-generator.ts, graph-emit-sink.ts, pdg-emit-sink.ts) from the same static RELATION_SCHEMA parse. Export the existing constant from csv-generator.ts (already imported by both sinks) instead. assertDeclaredPair now takes the pre-built pairKey rather than the two labels, since every caller (RelPairRouter.route, both sinks' addRelationship) needs that same key immediately after for its own Map/stream lookup on the per-streamed-edge hot path — avoids rebuilding the template string twice per edge. Also drops two schema.test.ts assertions that duplicated coverage already in the more narrowly-named regression tests below them, and trims the v32 ladder comment to point at assertDeclaredPair's docstring instead of re-explaining the same failure mechanism. * fix(schema): use replaceAll for the pair-arrow error message (CodeQL) .replace(str, ...) only touches the first match; CodeQL flags that as incomplete string escaping regardless of the caller's invariant that pairKey contains exactly one '|'. replaceAll is equivalent here and silences the alert. --------- Co-authored-by: Gergo Magyar <gergomagyar0@gmail.com>	2026-08-01 12:35:37 +01:00
ChunxueLi	c238085676	feat: make MAX_PROPERTY_DISPATCH_FANOUT configurable via env (#2726) ... * feat(scope-resolution): make MAX_PROPERTY_DISPATCH_FANOUT configurable via env * test(property-dispatch): add env override tests * docs(scope-resolution): document GITNEXUS_MAX_PROPERTY_DISPATCH_FANOUT in README and .env.example Add a dedicated troubleshooting subsection and .env.example entry for the GITNEXUS_MAX_PROPERTY_DISPATCH_FANOUT environment variable, matching the format used by the sibling GITNEXUS_MAX_CALLABLE_VALUE_TARGETS knob. Closes maintainer request: "Could you please document this in the readme plus the .env.example?" --------- Co-authored-by: Ubuntu <ubuntu@localhost.localdomain>	2026-08-01 12:18:07 +01:00
Void Freud	0f78179e7f	fix(jvm): enforce proximity-bounded sibling injection (#2732) ... * fix(jvm): bound same-package sibling injection * docs(jvm): document sibling injection cap * fix(jvm): mark truncated sibling sets incomplete and bound the merge Review follow-ups on the sibling injection cap (#2732): - The cap silently produced a third visibility state. Before it, a file was either fully visible (package under 500 files) or fully incomplete; once `injectedIds.size` hit the cap, real siblings were dropped while `isVisibilityIncomplete` still returned `false`. That flag gates wildcard attribution in seven Spring passes (`bean-candidates.ts:199` and the java/ kotlin bean-metadata, conditionals, config-bindings and DI resolvers), so 201-500-file packages — exactly this cap's population — resolved wildcard annotations against a truncated sibling set with no log signal. Truncation now marks the file incomplete and analyze warns once with the affected file count. - The cap only bounded `bindingAugmentations`; the two `typeBindings` merges below it still absorbed every sibling, so a class excluded from the binding set could still steer receiver/variable type inference through `scope.typeBindings`. Both halves now use the same bounded sibling set, and the merge iterates that set directly rather than filtering a full rescan, so the cap bounds the work as well as the result. - Path segments are split once per bucket instead of on every pairwise proximity comparison — that comparison runs O(files²) per package. - `JvmPackageFact` was re-declared locally instead of imported from `package-facts.js`, where the canonical declaration still serves both languages' facades and capture side-channels. Nothing kept the copies in sync. Restored the import. - README/.env.example: `GITNEXUS_MAX_INJECTED_SIBLINGS` does not lift the fixed 500-file package skip (including at `0`), and truncation disables wildcard attribution for the affected files. Both are now stated. * test(jvm): restore the language-facade coverage and pin the cap's behaviour The cap rewrite replaced the per-language harness with generic fixtures, dropping the Java/Kotlin capture-side-channel and facade coverage (package fact extraction, the 500-file skip, fail-closed on a file that produced no ParsedFile) and leaving a proximity fixture whose candidates were already in order — so it could not tell a working sort from plain truncation of the input. Restores that harness and adds cap-specific cases on top, driven through the shared JVM factory. The fixture interleaves near and distant siblings, so the retained set is only reachable by a working proximity sort. Covers: the exact capped set, truncation marking the file visibility-incomplete, type bindings bounded by the same sibling set, the unbounded `0` override staying complete, and the documented default of 200 applying when the variable is unset. Each new case fails against the pre-fix implementation. --------- Co-authored-by: Gergő Magyar <gergomagyar@icloud.com> Co-authored-by: Gergo Magyar <gergomagyar0@gmail.com>	2026-08-01 09:38:10 +01:00
Void Freud	7ee0df9e55	fix: serialize global registry transactions across processes (#2716) ... * fix: serialize global registry mutations * fix: serialize global registry mutations * fix: keep registry reads lock-free * test(registry): document cross-platform lock coverage * fix(registry): isolate the registry lock's namespace, timeout and diagnostics Review follow-ups on the global registry lock (#2716): - The lock took `getGlobalDir()` itself, which is byte-identical to a repo's index slot when that repo is rooted at the user's home directory (a real dotfiles layout). `runFullAnalysis` holds the per-repo lock across its whole pipeline and `acquireIndexLock` is not reentrant, so `registerRepo` / `adoptFlatBranchLabel` self-deadlocked until the wait ceiling and then failed the analyze. The registry now locks a private `<globalDir>/registry-lock` namespace no index slot can ever resolve to. - The lock inherited the index lock's 10-minute default timeout, sized for multi-minute analyze runs. `gitnexus augment` — documented to cold-start in under 500ms and shelled out from editor tool-use hooks — reaches it through `listRegisteredRepos({ validate: true })`. Registry transactions are sub-second, so they now get their own 5s ceiling. - Contention was silent: no `log`/`onWaitStart` was wired, and the primitive's own texts attribute a wait to "another gitnexus analyze", which misnames a registry holder. A registry-specific line is emitted on wait start instead. - On timeout the transaction now proceeds unlocked with a warning rather than throwing. The lost-update race it guards was unguarded before this branch, so degrading to the old best-effort behaviour beats failing `analyze`/`list`/ `index` outright — none of which wrap these calls in a handler — on a wedged lock. - `adoptFlatBranchLabel`'s recursive `fs.rm` no longer runs inside the lock; only the closing re-read/mutate/write does, mirroring `clean.ts`, which deletes the branch directory before calling the locked `removeBranchIndex`. A slow delete no longer blocks every registry operation on the machine. * test(registry): cover the remaining locked mutators and the colliding layout Three of the five functions the registry lock wraps had no overlap coverage, so a future narrowing of the lock would go unnoticed. Adds: - overlapping `removeBranchIndex` calls on two branches of one entry, - an overlapping `unregisterRepo` / `registerRepo` pair on distinct repos, - a registration issued while an index lock is held on the global directory, which reproduces the home-rooted self-contention the lock namespace fix addresses. Each fails without the corresponding fix: the two overlap tests lose an update when `withRegistryLock` is bypassed, and the collision test sees the wait announcement and the degraded-write warning once the lock namespace is reverted to `getGlobalDir()`. The collision test asserts on those log records rather than on elapsed time, so it stays deterministic on a slow runner. * perf(registry): keep the validation walk out of the registry lock `listRegisteredRepos({ validate: true })` held the global lock across its read-only validation walk — an `fs.access` per entry, slow on a network mount or a large registry — even though the common case prunes nothing and writes nothing. That is the same lock `gitnexus augment` takes on every editor tool call, so unrelated registry work serialized behind a walk that never touched the file. The walk now runs unlocked; the lock is taken only when an entry is provably gone, and the prune is applied to a snapshot re-read inside it, so a registration that lands during the walk is no longer clobbered by a stale write. Same shape as the `adoptFlatBranchLabel` split. --------- Co-authored-by: Gergő Magyar <gergomagyar@icloud.com> Co-authored-by: Gergo Magyar <gergomagyar0@gmail.com>	2026-08-01 08:47:14 +01:00
Gergő Magyar	064832f50c	fix(mcp): resolve false FTS-missing warnings in the query tool (#2773) ... * fix(mcp): surface resolved repo/branch/indexed-at in the FTS-degraded warning Turns the generic "FTS indexes missing" message into a diagnostic that reveals what this MCP session actually resolved, so a CLI/MCP mismatch or stale-connection theory is visible in the warning text itself instead of requiring a separate debugging round-trip (#2767). * fix(mcp): stop swallowing real FTS query errors behind the missing-index message queryFTSViaExecutor previously collapsed 'index genuinely missing' and 'a real query/connection error occurred' into the same silent null, so a real failure could masquerade as the generic FTS-degraded message with no diagnostic trail — even when it happened on only some of the per-table queries while others succeeded. Classifies the failure (mirroring queryFTS's own check for this exact cypher call), always logs a non-benign error server-side regardless of overall outcome, and surfaces it (redacted) in the client warning only when every table failed (#2767). * fix(mcp): give --repair-fts a dedicated freshness signal for warm readers --repair-fts intentionally never restamps indexedAt (it doesn't regenerate the graph), so a long-lived MCP session's pool staleness check had no explicit signal that a repair happened, only the incidental file-identity delta. Reuses the existing (forensic-only) capabilities.fts.status field: repair-fts now stamps just that sub-field (everything else byte-identical), and ensureInitialized compares it as a third, independent reinit trigger alongside the existing stamp/identity checks, seeded at cold init too so a fresh process's first warm check doesn't false-trigger (#2767). * test(mcp): warm session picks up an out-of-band --repair-fts rebuild (#2767) New end-to-end integration test: a real writable LadybugDB session builds an index WITHOUT FTS, a real LocalBackend observes 'FTS indexes missing' through the real pool, a separate writable session performs the exact repair-fts writes (real createSearchFTSIndexes + the #2767 capability-only meta stamp), and the SAME still-warm backend re-queries successfully without a restart — closing the one end-to-end gap no existing test covered. Running this against the real engine surfaced a second real message shape for a missing FTS index ("doesn't have an index with name X", not just "does not exist") that the U2 classifier didn't recognize — fixed classifyFtsQueryError to match both, with a regression test pinning the exact observed string. * fix(review): address code-review findings on the #2767 FTS fix - Anchor classifyFtsQueryError to the exception class (mirroring isBenignDropFtsIndexError) instead of a bare substring search, so a real, differently-classed error that happens to echo the benign phrase in its body (e.g. an echoed user query) can't be misclassified as a benign missing-index (adversarial review). - Re-read the on-disk meta immediately before the --repair-fts capability stamp write instead of reusing the pre-rebuild snapshot, so a concurrent writer (e.g. the HTTP server's background embedding checkpoint job) landing mid-repair isn't silently reverted. - Surface a client-facing partial-result warning (mirroring the existing enrichmentDegraded convention) when some FTS tables succeed but at least one hits a real error, instead of only logging it server-side. - Update RepoMeta.capabilities' stale 'no programmatic readers' docstring now that ensureInitialized reads capabilities.fts.status. - Widen the warm-session integration test's polling deadline for more margin over the production 5s staleness-check throttle. * fix(ci): drop the cold-init loadMeta call ensureInitialized never needed It stole the mocked loadMeta call an unrelated upstream PDG test depends on (test/integration/impact-pdg-statement-precise.test.ts queues a single mockResolvedValueOnce for its own PDG-config read; the extra call consumed that slot before the PDG code ran, so it fell through to the mock's null default and epistemic came back undefined instead of 'pdg-intra-procedural'). Cold init now leaves lastObservedFtsStatus unseeded — the cost is at most one redundant initLbug call on the first warm check, which no-ops via a single fs.stat when nothing actually changed, not a real reopen. * fix(review): address tri-review findings on the #2767 FTS fix Fixes two P1s (misleading repair-fts advice on real query errors; embedding-checkpoint job silently reverting the capabilities.fts stamp for up to its 30-minute lifetime), five P2/P3s (stale indexedAt in warnings, extension-unavailable noise, mismatched log severity, a table-missing vs index-missing conflation confirmed against a live LadybugDB, and a reinit-watermark latching bug), and the four residual items already self-disclosed in this PR's description (shared FTS error classifier, consolidated per-pool observed-state map, a redactPaths whitespace gap, and an isolated ftsCapsChanged test). A /simplify pass afterward caught one more real bug: the extension-unavailable short-circuit only guarded the MCP pool path, so the CLI-path fix above it started surfacing spurious non-benign errors for the same expected degraded state the pool path stays silent on — now both paths agree. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: Gergo Magyar <gergomagyar0@gmail.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-01 08:42:51 +01:00
azizur100389	84f584449d	fix(python): resolve classes through module imports (#2770)	2026-08-01 06:02:47 +01:00
dependabot[bot]	51095c19f8	chore(deps): bump actions/setup-python from 6.3.0 to 7.0.0 (#2757) ... Bumps [actions/setup-python](https://github.com/actions/setup-python) from 6.3.0 to 7.0.0. - [Release notes](https://github.com/actions/setup-python/releases) - [Commits](ece7cb06ca...5fda3b95a4) --- updated-dependencies: - dependency-name: actions/setup-python dependency-version: 7.0.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>	2026-07-31 13:05:18 +01:00
azizur100389	454d383416	fix(ingestion): join multi-line closure bindings on initializer startLine (#2735) (#2762) ... * fix(ingestion): join multi-line closure bindings on initializer startLine Graph-node captures sit on the outer binding wrapper while scope-resolution anchors on the inner callable; the line-only position join missed when those split across lines and fail-closed dropped the real CALLS edge (#2735). * fix(ingestion): unwrap Ruby call+block for multi-line lambda joins Cover Kotlin/Ruby/Dart multi-line closure CALLS in integration tests, and dig Ruby's call/block field so do-end bindings join on the block start line. * style(ingestion): format closure join changes * fix(ingestion): make closure position join language agnostic	2026-07-31 11:58:47 +01:00
dependabot[bot]	d99d828a52	chore(deps)(deps): bump express-rate-limit in /gitnexus (#2764) ... Bumps [express-rate-limit](https://github.com/express-rate-limit/express-rate-limit) from 8.6.0 to 8.6.1. - [Release notes](https://github.com/express-rate-limit/express-rate-limit/releases) - [Commits](https://github.com/express-rate-limit/express-rate-limit/compare/v8.6.0...v8.6.1) --- updated-dependencies: - dependency-name: express-rate-limit dependency-version: 8.6.1 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Gergő Magyar <gergomagyar@icloud.com>	2026-07-31 10:42:37 +01:00
dependabot[bot]	e0dc0c2d5e	chore(deps): bump release-drafter/release-drafter from 7.5.1 to 7.6.0 (#2756) ... Bumps [release-drafter/release-drafter](https://github.com/release-drafter/release-drafter) from 7.5.1 to 7.6.0. - [Release notes](https://github.com/release-drafter/release-drafter/releases) - [Commits](4d75298e00...eada3c96a6) --- updated-dependencies: - dependency-name: release-drafter/release-drafter dependency-version: 7.6.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Gergő Magyar <gergomagyar@icloud.com>	2026-07-31 10:34:51 +01:00
dependabot[bot]	909f2f85b6	chore(deps): bump the codeql-action group across 1 directory with 3 updates (#2755) ... Bumps the codeql-action group with 3 updates in the / directory: [github/codeql-action/init](https://github.com/github/codeql-action), [github/codeql-action/analyze](https://github.com/github/codeql-action) and [github/codeql-action/upload-sarif](https://github.com/github/codeql-action). Updates `github/codeql-action/init` from 4.37.0 to 4.37.3 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](99df26d4f1...e4fba868fa) Updates `github/codeql-action/analyze` from 4.37.0 to 4.37.3 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](99df26d4f1...e4fba868fa) Updates `github/codeql-action/upload-sarif` from 4.37.0 to 4.37.3 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](99df26d4f1...e4fba868fa) --- updated-dependencies: - dependency-name: github/codeql-action/analyze dependency-version: 4.37.3 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: codeql-action - dependency-name: github/codeql-action/init dependency-version: 4.37.3 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: codeql-action - dependency-name: github/codeql-action/upload-sarif dependency-version: 4.37.3 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: codeql-action ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Gergő Magyar <gergomagyar@icloud.com>	2026-07-31 10:34:35 +01:00
dependabot[bot]	e8e572fbff	chore(deps)(deps): bump i18next from 26.3.0 to 26.3.6 in /gitnexus-web (#2751) ... Bumps [i18next](https://github.com/i18next/i18next) from 26.3.0 to 26.3.6. - [Release notes](https://github.com/i18next/i18next/releases) - [Changelog](https://github.com/i18next/i18next/blob/master/CHANGELOG.md) - [Commits](https://github.com/i18next/i18next/compare/v26.3.0...v26.3.6) --- updated-dependencies: - dependency-name: i18next dependency-version: 26.3.6 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Gergő Magyar <gergomagyar@icloud.com>	2026-07-31 10:34:16 +01:00
MyShining	de84ad6297	feat(spring): index @Bean factories and @Resource injection (#2740) ... * feat(spring): index Bean factories and Resource injection * fix(spring): address Bean and Resource review findings * refactor(lbug): keep relation pair parsing in router * test(lbug): preserve schema exports in WAL mocks * test(cache): align schema bump pin --------- Co-authored-by: Shining <xuenning@qiyi.com> Co-authored-by: Gergo Magyar <gergomagyar0@gmail.com>	2026-07-31 10:33:42 +01:00
dependabot[bot]	5ed9617ff4	chore(deps)(deps): bump @langchain/core in /gitnexus-web (#2749) ... Bumps [@langchain/core](https://github.com/langchain-ai/langchainjs) from 1.2.2 to 1.2.3. - [Release notes](https://github.com/langchain-ai/langchainjs/releases) - [Commits](https://github.com/langchain-ai/langchainjs/compare/@langchain/core@1.2.2...@langchain/core@1.2.3) --- updated-dependencies: - dependency-name: "@langchain/core" dependency-version: 1.2.3 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Gergő Magyar <gergomagyar@icloud.com> Co-authored-by: Abhigyan Patwari <126312502+abhigyanpatwari@users.noreply.github.com>	2026-07-31 08:59:03 +00:00
dependabot[bot]	c1ee62854a	chore(deps)(deps-dev): bump @babel/types in /gitnexus-web (#2750) ... Bumps [@babel/types](https://github.com/babel/babel/tree/HEAD/packages/babel-types) from 8.0.0 to 8.0.4. - [Release notes](https://github.com/babel/babel/releases) - [Changelog](https://github.com/babel/babel/blob/main/CHANGELOG.md) - [Commits](https://github.com/babel/babel/commits/v8.0.4/packages/babel-types) --- updated-dependencies: - dependency-name: "@babel/types" dependency-version: 8.0.4 dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Gergő Magyar <gergomagyar@icloud.com>	2026-07-31 08:32:45 +00:00
dependabot[bot]	59ea1ce2c8	chore(deps)(deps-dev): bump @types/node in /gitnexus (#2763) ... Bumps [@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node) from 26.1.1 to 26.1.2. - [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases) - [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node) --- updated-dependencies: - dependency-name: "@types/node" dependency-version: 26.1.2 dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>	2026-07-31 07:58:11 +01:00
dependabot[bot]	c0f2eb594e	chore(deps)(deps-dev): bump @vitejs/plugin-react in /gitnexus-web (#2753) ... Bumps [@vitejs/plugin-react](https://github.com/vitejs/vite-plugin-react/tree/HEAD/packages/plugin-react) from 6.0.2 to 6.0.4. - [Release notes](https://github.com/vitejs/vite-plugin-react/releases) - [Changelog](https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react/CHANGELOG.md) - [Commits](https://github.com/vitejs/vite-plugin-react/commits/plugin-react@6.0.4/packages/plugin-react) --- updated-dependencies: - dependency-name: "@vitejs/plugin-react" dependency-version: 6.0.4 dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>	2026-07-31 07:57:50 +01:00
dependabot[bot]	7890798192	chore(deps)(deps-dev): bump @types/node in /gitnexus-web (#2752) ... Bumps [@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node) from 25.9.5 to 26.0.1. - [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases) - [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node) --- updated-dependencies: - dependency-name: "@types/node" dependency-version: 26.0.1 dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>	2026-07-31 07:57:31 +01:00
Gergő Magyar	27ab37c432	feat(resolution): type receiver chains from AST structure across all 14 languages (#2708) + epistemic lower-bound (#2744) (#2747)	2026-07-31 07:12:57 +01:00
Gergő Magyar	9c24e3459e	fix(rust): qualify items by their enclosing mod chain so same-named ones stay distinct (#2742) (#2745) ... * fix(rust): let the qualified-call filter see inline modules The negative filter added in #2741 builds its set of known module names from FILE PATHS, so an inline `mod x { … }` — which appears in no path — was absent from it. Every module-qualified call into an inline module was therefore rejected before any candidate channel ran, which is a hole in that optimisation rather than in the resolution logic it guards. The per-pass index now unions the file-derived names with inline module names taken from the scope model: a `mod` declaration binds a `Namespace` def locally in the declaring scope, and that binding is the only place an inline module's name exists. Collected in the same walk that already builds the module → scope map, so it costs no extra pass. Found while fixing #2742, where a correctly resolved call into `mod inner { … }` still could not reach its target. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(scope-resolution): try the namespace-prefixed node key before the bare one `resolveDefGraphId` looked up the plain `qualifiedName` key first and only retried with the `namespacePrefix`-qualified key afterwards. For the defs that carry a prefix the qualified name is a bare TAIL, so the plain key happily matched a same-named item at a different namespace depth in the same file and returned it before the more specific retry was ever reached. The namespace-prefixed key is strictly the more specific of the two, so it is now tried first. Where no such node exists the lookup falls through to exactly the previous order, which keeps the #1982 behaviour this retry was added for. Without this, a call into `mod inner { fn dispatch }` resolved to the correct definition and then mapped it onto the crate-root `fn dispatch` node — the self-loop #2742 describes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(rust): qualify items by their enclosing mod chain so same-named ones stay distinct (#2742) Node identity is `<label>:<file>:<qualifiedName>` and carried no module path, so an inline `mod inner { fn dispatch }` and a crate-root `fn dispatch` in the same file collapsed onto `Function:<file>:dispatch`, first-wins. Resolution already picked the right definition — the target simply was not representable, so a correct resolution still rendered as a self-loop and `impact` reported the real callee as unreached. The mechanism already existed: `qualifyRustImplTargetByModScope` has walked `mod_item` ancestors for impl targets since #1982. Generalised to `qualifyByEnclosingModScope` and applied to free items, so `mod inner { fn dispatch }` becomes `Function:<file>:inner.dispatch`. Keyed purely on the `mod_item` node type, exactly as the impl qualifier already was, so it is a no-op for every language whose grammar has no such node. Two constraints found by tests rather than by reading, both now encoded: - The helper normalised `::` to `.` unconditionally. With no enclosing `mod` that rewrote a top-level `impl a::Inner` from `a::Inner` to `a.Inner` and moved its node id away from the one the HAS_METHOD owner edge emits, breaking the #1975 scoped-impl ownership. It now returns raw text untouched when there are no mod segments, which also makes the change strictly additive for every id that has no enclosing module. - Qualification is scoped to items with no enclosing class/impl. A method already carries its owner's name, and that owner's id is mod-scoped by the impl qualifier, so qualifying the method again breaks the same byte-for-byte agreement. Same-named methods on same-named types in sibling modules therefore still collapse — a narrower residual than the free-item case fixed here, and one belonging to the owner edge rather than to this path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(storage): bump schema versions for the mod-qualified Rust node ids (#2742) `INCREMENTAL_SCHEMA_VERSION` 24 -> 25 and `SCHEMA_BUMP` 31 -> 32. Node ids change for every Rust item inside any `mod` block, and `#[cfg(test)] mod tests` makes that close to every Rust repository. A pre-v25 index therefore holds ids an incremental top-up cannot reconcile — the old nodes would simply be stranded — so the reuse gate has to force a full re-analyze. The qualified name is computed in the parse worker, so a warm parse cache would likewise replay the old unqualified ids and keep the collapse. This branch originally claimed v24; #2708 took that number and merged first, so it is renumbered to v25 here. That is exactly the collision the v29 note in parse-cache.ts warns about, and re-checking against origin/main at rebase time rather than at branch time is what caught it. #2708 did not touch `SCHEMA_BUMP`, so 32 is free. The version-pin test moves with the bump by design, including the new pre-v25 row in the reuse-gate table. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(rust): stop mod-qualifying container ids while their owner edges stay bare (#2745 review) #2742 re-keyed Rust node ids by the enclosing `mod` chain. The mint moved; the owner-edge anchor did not. `findEnclosingClassInfo` mints a member's owner id from the container's BARE `nameNode.text` and only follows a qualified shape when the provider sets `classExtractor.qualifiedNodeId`, which Rust does not. So every `struct` / `trait` / `enum` / `impl` declared directly inside a `mod` got a node id that none of its member edges pointed at. Five lines of idiomatic Rust were enough: pub mod engine { pub struct Config { pub retries: usize } } NODE Struct:src/lib.rs:engine.Config DANGLING HAS_PROPERTY Struct:src/lib.rs:Config -> Property:src/lib.rs:Config.retries The rows are discarded by the IGNORE_ERRORS COPY retry, so the struct silently lost every field. A trait impl inside a `mod` additionally dropped its METHOD_IMPLEMENTS edge outright. The same gap put `impl a::Inner` inside a `mod` back on the #1975 rake that `qualifyByEnclosingModScope`'s own docblock warns about. The impl-target branch deliberately fires only for an UNSCOPED `type_identifier`; the new gate had no such restriction and picked up the scoped targets that branch had just excluded, minting `Impl:<file>:outer.a.Inner` against an anchor still reading `Impl:<file>🅰️:Inner`. The member side was already excluded via `!enclosingClassInfo`. This adds the owner side, gated on `MEMBER_OWNER_NODE_TYPES` — derived from `CLASS_CONTAINER_TYPES`, which is already the single source of "this node type owns member edges" and already carries an INVARIANT note binding it to `CONTAINER_TYPE_TO_LABEL`. A language adding a container therefore cannot gain a mismatched id shape here without also failing that invariant. Keyed purely on tree-sitter node types, so no language name enters shared ingestion. `union_item` is listed too: its fields are captured as Property but it is not a recognized owner, so they carry no HAS_PROPERTY edge and cannot dangle — it is here so a union's id keeps the same shape as the struct beside it. Containers still collapse across sibling modules, exactly as before this fix. That residual belongs to the owner edge, and is not worked around here. Regression tests use the UNFILTERED `findDanglingEdges(result)`. Every other dangling assertion in `rust.test.ts` passes `['HAS_METHOD']`, which is precisely why the HAS_PROPERTY breakage shipped with a green suite. They assert the NODE id rather than only the edge's anchor, because the anchor was already bare while the bug was live — an edge-only assertion passes in both builds. All four fail when the new gate clause alone is reverted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019GvVxWt1ShhEP8CiMj3b6Z * fix(rust): resolve modules nested inside an inline mod (#2745 review) The #2730 self-loop survived one `mod` deeper: pub mod outer { pub mod tools { pub fn dispatch() {} } pub fn dispatch() { tools::dispatch(); } } CALLS outer.dispatch -> outer.dispatch <- the #2730 symptom NODE outer.tools.dispatch <- correct target, unlinked Two gates were blind to a nested inline module, so the hook refused and the shared lexical tier bound the call to the enclosing same-name `dispatch`: `knownModuleNames` was collected by walking `moduleScopeByFile`, which maps a file to its ROOT `Module` scope only. A `mod` nested inside an inline `mod` binds in the parent module's scope, so the walk saw depth-1 inline modules and missed every nested one — `tools` never entered the set and the negative filter rejected the qualifier before any candidate ran. `declaresSubmodule` had the same root-only assumption, so even with the name known the candidate `outer::tools` was never yielded. Both now read the def index. Names come from every `Namespace` def; inline module PATHS are derived from the members' `namespacePrefix` rather than from the `mod` defs, because a `mod` def carries no nesting information of its own — inside `mod outer { mod tools { … } }` the inner def is `qualifiedName: 'tools'` with NO `namespacePrefix`, while every def within it is stamped `outer.tools`. A `Namespace` scope also owns its OWN def rather than its children's, so the scope tree cannot answer this either: the `mod outer` scope lists `outer`, never `tools`. Restricted to non-empty prefixes, so this stays a DECLARATION check. Including file-derived modules would let an undeclared or `cfg`-gated file on disk outrank a real `use` binding — the regression #2741's review already fixed once. File-backed submodules therefore keep going through the binding check. A module with no defs at all is absent from the set, which is harmless: it has no member for a qualified call to resolve to. Cost is one pass over an already-resident def index, memoized per resolution pass on the existing WeakMap — the same order of work as the binding walk it replaces, and it subsumes it. `isLocalNamespaceBinding` was going to single-source the duplicated "locally declared submodule" predicate the review flagged; deriving paths from members removed the second copy outright instead. Regression fixture covers depth 2 and depth 3, so the fix is depth-agnostic rather than depth-2 special-cased. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019GvVxWt1ShhEP8CiMj3b6Z * fix(rust): let an imported type outrank a same-named module (#2745 review) Widening the negative filter to inline `mod` names let a type-qualified call through whenever a module happened to share the type's name. The crate-root-relative candidate then captured it: // src/lib.rs pub mod Buffer { pub fn with_capacity() -> usize { 111 } } // src/b.rs use crate::c::Buffer; // the real target lives in c.rs pub fn call() -> usize { Buffer::with_capacity() } base: (no CALLS edge — unresolved) PR: CALLS b::call -> Function:src/lib.rs:Buffer.with_capacity <- fabricated `ids.ts` states the doctrine this broke: a missing edge is the correct failure direction for a graph whose consumers include `impact`; a fabricated caller is not. The base produced the missing edge and the PR produced the fabricated one. That third candidate is the loosest of the three — a guess at a crate-root-relative path the caller never wrote, kept for 2015-edition style. In Rust 2018 a bare first segment resolves in the CALLER's module, so a local binding for that segment settles the question: it is now skipped when the head names anything non-module in the caller's own module. Candidates 1 and 2 are untouched, and they run first, so the legitimate `use crate::tools;` path is unaffected. The binding lookup goes through `lookupBindingsAt`. A first attempt read `Scope.bindings` directly and the guard never fired: a `use` binding is finalize OUTPUT and absent from the scope's own local table, which is exactly the imported-type case being guarded. Contract I8 in `contract/scope-resolver.ts` requires that channel anyway. The regression test asserts the forbidden TARGET rather than an empty edge set, and separately asserts the module member still exists as a node — otherwise the test would pass just as well if the call went unresolved for some unrelated reason, or if the module node disappeared entirely. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019GvVxWt1ShhEP8CiMj3b6Z * fix(scope-resolution): try the namespace-prefixed name on the TAGGED keys too (#2745 review) `resolveDefGraphId` gained a namespace-prefixed retry for the plain qualified key in this PR, but the five tagged keys above it — template constraints, parameter types, parameter shape, arity, template arguments — kept composing from the bare `qualifiedName`. For a namespace- or `mod`-qualified def those keys are simply dead: `node-lookup.ts` registers them under the QUALIFIED name (`inner.dispatch#0`) while this side built `dispatch#0`. The keys exist to separate overloads, so a mod-scoped overload set was relying on whichever later key happened to catch it. Verified as a miss rather than a mis-hit before changing anything — an end-to-end run with a crate-root decoy of the same name and arity binds correctly — so this is hygiene, not a live bug. Worth doing while the code is open rather than leaving five keys dead and the behaviour dependent on fallback order. Both name forms now go through one `lookupTagged` helper, most specific first, so a sixth tagged key cannot be added with the bare form only. That also removes the five hand-repeated `qualifiedKey(...)` / `nodeLookup.get(...)` pairs. Also pins the C++ `EXTENDS` retarget this PR's reorder produces. `cpp-two-phase-dependent-base-cross-ns-deep` declares a global `Inner` decoy alongside `ns:🅰️🅱️:Inner`; the base's `qualifiedName` is a bare `Inner` with the path on `namespacePrefix`, so only the prefixed key separates them, and only if it runs first. The improvement was riding unasserted in a Rust-scoped PR. The captures golden covers every `rust-*` fixture, so the three fixtures added by this review series drift it; regenerated with UPDATE_GOLDEN=1. Verified: 785 tests across cpp / csharp / rust resolvers and the callable-id-lockstep unit test. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019GvVxWt1ShhEP8CiMj3b6Z * fix(rust): keep a mod declared inside a fn from hoisting above the callable (#2745 review) `fn wrapper() { mod helper { fn dispatch } }` minted `Function:<file>:helper.wrapper.dispatch@2:8` — the mod segment composed OUTSIDE the enclosing-callable prefix, inverting the real nesting. Nothing dangled: the `@line:col` suffix already makes a function-local callable's id unique, which is also why the mod segment adds no identity in this position. The path simply read as a lie about the source. It is now skipped rather than reordered — interleaving two qualifier passes to fix the order would be real machinery for a shape whose ids are already unique. Also folds in the three documentation and structure findings from the same review: - The 4-clause gate is extracted to a named `qualifiesByEnclosingModScope`, matching the two conditions directly above it in the same function, which were already named consts. - `qualifyByEnclosingModScope`'s docblock documented only the impl-target contract even though the generalized name has had a second, looser caller since #2742. It now states both, and says which gate belongs to which — that gap is what let the #1975 scoped-impl regression through in the first place. - The "cheap rejection BEFORE any index work" comment was no longer true: `passIndexFor` walks the def index on its first call in a pass. Corrected rather than left to mislead the next reader into thinking the filter is free. What it still buys — skipping the per-site candidate search, the part that scales with the workspace — is stated instead. Verified: 279 tests across the Rust resolver suite and the Rust scope-resolution unit tests. Captures golden regenerated for the extended fixture. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019GvVxWt1ShhEP8CiMj3b6Z * test(storage): move main's SCHEMA_BUMP pin to 32 for the mod-qualified ids (#2745 review) `#2736` added a pin asserting `SCHEMA_BUMP === 31` on main, which arrived on this branch through the merge of main while `0062a5c2` had already bumped the constant to 32. Neither side conflicted textually — the pin and the constant live in different files — so the merge was clean and the test failed instead. That is the pin working as designed: it exists so a bump cannot ride along unnoticed, and this is the fifth time a SCHEMA_BUMP collision has been caught by a guard rather than by review. Updated to 32 with the reason recorded inline. `INCREMENTAL_SCHEMA_VERSION` needs no second bump: 25 was introduced by this unmerged branch, so no released index carries it, and its own pin in `call-summary-schema-version.test.ts` is already consistent. Verified: 119 tests across the parse-cache, schema-version, incremental-orchestration and the two identity suites that arrived with the merge. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019GvVxWt1ShhEP8CiMj3b6Z * test(bench): rebaseline the Rust capture fingerprint for the three new fixtures (#2745 review) CI caught what I missed: [scope-capture --check] FAIL: rust: capture fingerprint drift (got 05acbaca..., expected 90fda086...) fixture_count 202 `bench/scope-capture` fingerprints the whole `rust-*` fixture corpus, so the three fixtures added by this review series drift it. I rebaselined the `rust-captures-golden` snapshot and stopped there — a new fixture is a call site of BOTH, and updating only one is how this reached CI red. This is the same class as PR #2743's headline finding, from the other direction: an id-shape change makes every synthetic corpus a call site, and the author fixed the unit-test fixture and missed the bench. Here it is a fixture-count change rather than an id-shape change, and the review that flagged the #2743 lead as "REFUTED, bench/ has no Rust node-id corpus" was right about node ids and wrong about the corpus fingerprint. Noted for the next author in the baseline entry itself. Verified as pure corpus growth rather than a capture-logic shift: removing ONLY the three new fixture directories and re-running reproduces the prior fingerprint exactly (196 fixtures, capture_groups_fp 3432), and restoring them gives the new one (202, 3556). `emitRustScopeCaptures` is untouched by this series. Scaling 1.022 local / 1.057 CI, well inside the 1.5 budget. `bench/python-scope` globs `python-*` only and is unaffected; no other bench walks the Rust corpus. `--check` now PASSes for all 15 languages. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019GvVxWt1ShhEP8CiMj3b6Z --------- Co-authored-by: Gergo Magyar <gergomagyar0@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 17:08:00 +01:00
azizur100389	e723f3c2ee	fix(scope-resolution): parse def coordinates after file paths (#2743) ... * fix(scope-resolution): parse def coordinates after file paths Anchor coordinate parsing to the known file path so coordinate-like path fragments and private symbol names cannot corrupt closure attribution. * fix(bench): use production definition ids	2026-07-30 07:34:32 +01:00
azizur100389	bee3e82ab2	test(scope-resolution): guard closure identity invariants (#2748)	2026-07-30 05:34:21 +01:00
Gergő Magyar	bc76ba2f25	fix(resolution): type inline constructor receivers in every spelling (#2708) (#2737) ... * fix(resolution): resolve constructor-expression receivers (#2708) `Service(db).do_work()` emitted no CALLS edge, so the caller was missing from `impact(direction: "upstream")` and `context()` while the two-step spelling of the same call (`s = Service(db)` then `s.do_work()`) resolved. The receiver reaches `resolveCompoundReceiverClass` intact — Case 0 in `receiver-bound-calls` routes it there because the text contains `(`. The free-call branch then only knew one shape: a function whose return-type binding names a class. A class has no return-type binding, so `Service` resolved to nothing and the member call was dropped. Handle the constructor shape: in languages that construct without a `new` keyword (Python, Kotlin, Swift, Scala) a free call naming a class IS a constructor call, so the expression's type is that class. The existing return-type path still runs first and wins, keeping this strictly additive — `new`-keyword languages never reach the new line because their receiver text keeps the keyword (`new Service(db)`), which matches no class binding. Verified on the issue's 4-file repro: `route_inline` now emits `CALLS → Service.do_work` and `impactedCount` goes 1 → 2. Note the issue's second ask — degrading `epistemic` to `lower-bound` when a receiver goes unresolved — is NOT addressed here. `computeEpistemicBoundary` keys only on the target's own heritage edges and runs at query time against the index, while unresolved references live in an in-memory `resolutionOutcomes[]` that is never persisted. That needs unresolved-receiver counts in the index first, so it is left for a follow-up. Tests: new `python-inline-constructor-receiver` fixture plus three integration cases (inline resolves, two-step still resolves, no cross-class fan-out). Two of the three fail without the source change. Full `test/integration/resolvers` suite passes (2928 tests) — the fix is shared across every language, so no-regression coverage matters more than the new cases. Python captures golden regenerated: additions only, no existing digest changed, confirming capture output is untouched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqnsJK3Cnbu3bjdZbzgMMP * refactor(resolution): state the construction rule once, cover every spelling (#2708) The first commit fixed `Service(db).do_work()` by special-casing a bare class-name callee inside the free-call branch of the compound receiver resolver. That was the right rule in the wrong place: it covered one surface syntax out of three, and asserted rather than declared which languages it applied to. Probing the same shape across languages showed the bug is wider: | spelling | languages | dropped before? | |------------------------|--------------------|-----------------| | `Service(db).m()` | Python | yes | | `new Service(db).m()` | JS/TS, Java, C# | yes | | `Service.new.m()` | Ruby | yes | | both forms | PHP, Swift, Dart, | no — already | | | Kotlin | resolved | So the rule is stated once — "constructing a class yields an instance of that class" — and the per-language surface syntax is declared through a new `ScopeResolver.constructionSyntax` hook, matching how this file already gates language-varying behaviour (`stripReceiverCastExpressions`, `hoistTypeBindingsToModule`). Shared pipeline code names no language. - `bare: true` — Python - `keyword: 'new'` — JS/TS, Java, C# - `selector: 'new'` — Ruby, including the parenthesis-less `Service.new` spelling that reaches the chain walker rather than the call branch Opt-in is per-language for two reasons. Correctness: `bare` would mistype `stat(&st).field` in C, where a struct and a function may share a name. Evidence: PHP, Swift, Dart and Kotlin resolve this shape already, so they stay unwired instead of carrying a declaration that changes nothing — each verified by diffing analyzer output between builds with and without the change, not assumed. The keyword gate also keeps a bare factory call honest: in a `new` language, `makeOther(db).doWork()` still resolves through the factory's return type and is never read as constructing a same-named class. Tests: TypeScript fixture (inline `new`, a plain `.js` file for the javascript provider, two-step, and the factory guard) and a Ruby fixture (`Service.new` with and without an argument list, plus two-step). With the source change stashed, the inline cases fail and the factory/two-step cases still pass. The Python cases from the first commit are unchanged. No Kotlin fixture: its cases passed without the change, so they would document coverage this commit does not provide. Full `test/integration/resolvers` + `test/unit/scope-resolution`: 4234 passed, 1 skipped. Ruby captures golden regenerated — additions only, no existing digest changed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqnsJK3Cnbu3bjdZbzgMMP * fix(resolution): only treat a construction selector as construction on the class itself (#2708) The `selector: 'new'` rule fired on any receiver whose type was class-like, which is true both when the receiver IS the class constant (`Factory.new`) and when it is a value of that class (`factory.new`). `isClassLike(...)` cannot tell those apart, so an instance receiver took the construction path too and skipped the member lookup that should have run. That replaced a CORRECT edge with a wrong one. Measured against the base build on a class defining an instance method `new` returning a `Product`: factory = Factory.new; factory.new.run before this PR: Product#run (correct) after this PR: Factory#run (wrong) Track whether resolution currently sits on the class constant or on a value of that class, and apply the selector rule only to the former. The head of a chain is a class constant only when it resolved straight to a class binding rather than through a typeBinding; every hop past it yields a value, so the flag clears. The `obj.method()` branch derives the same fact from whether `objExpr` is a bare name resolving to that class. `Factory.new.run` keeps the behaviour this PR introduced (Factory#run), which is itself a fix over the base build's Product#run. KNOWN LIMITATION, now documented on the contract field and asserted by a test so a future change to it is deliberate: a class-level override (`def self.new` returning another type) is still read as construction. The scope model records no staticness per member, so `def new` and `def self.new` are indistinguishable at this layer; separating them needs the language provider to record staticness first. An earlier attempt to use `TypeRef.source` as a proxy was abandoned after tracing showed Ruby records body-inferred return types as `return-annotation` too, so it does not discriminate. Tests: `ruby-construction-selector` fixture pins all three shapes — class constant, instance receiver, and the documented class-level-override limitation. Ruby resolver suites: 185 passed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqnsJK3Cnbu3bjdZbzgMMP * fix(resolution): resolve generic construction receivers (#2708) `new Box<string>().unwrap()` reached the class lookup as `Box<string>`, which names no class binding, so the member edge was still dropped while the non-generic spelling resolved. `new Foo<T>()` is ordinary in all three keyword-wired languages, so the fix covered a materially narrower slice of real code than intended. Retry the lookup on the base name via `stripTemplateArguments` — the same normalization `resolveClassBindingForName` already applies to typed receivers in the sibling `receiver-bound-calls` pass. The exact-name lookup still runs first, so a class whose name legitimately contains `<` is unaffected. Measured on the probe that first showed the gap: before: | viaGeneric | Class:src/box.ts:Box | (construction edge only) after: | viaGeneric | Method:src/box.ts:Box.get#0 | (member edge resolved) Tests: `viaGenericCtor` added to the typescript-inline-constructor-receiver fixture, asserting both the target file and that the resolved id is `Box`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqnsJK3Cnbu3bjdZbzgMMP * fix(resolution): resolve construction in the chain-head position (#2708) `new Service(db).inner.deep()` emitted only the construction edge. The chain walker seeds its starting class from the head segment, which arrives as `new Service(db)` and reduces via `stripCallParens` to `new Service` — no binding and no class of that name, so the walk was never seeded and every segment after it resolved to nothing. Seed the head through the same construction rule the call branch already uses. A constructed value is an instance, so the class-constant flag from the previous commit correctly stays false — `new Factory().new` does not get the selector treatment. The gap was asymmetric across the languages this PR wires: Python's bare form strips to a plain `Service` and was already seeded, so only the keyword languages were affected. Tests: `viaChainHead` added to the typescript-inline-constructor-receiver fixture. Note the fixture annotates `readonly inner: Inner` explicitly — with an unannotated initializer the walk stops at the field, which is field-type inference and a separate concern from head seeding. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqnsJK3Cnbu3bjdZbzgMMP * fix(resolution): match the construction keyword by token, not by one space (#2708) The keyword form was matched with `startsWith(`${keyword} `)`, so only a single space separated `new` from the type. Any other trivia the source used — a tab, a line break — failed the match and the member-call edge was lost. Match the keyword as a whole token followed by one or more whitespace characters instead. `newService()` still fails the match, which is the point: it is an ordinary call, not a construction, and must keep resolving through its own return type. The keyword is escaped before it enters the pattern. It comes from a language provider rather than from user input, but a keyword containing a regex metacharacter would otherwise build a silently wrong pattern. Tests: tab-separated and newline-separated `new` added to the typescript-inline-constructor-receiver fixture. Note these cases only survive because `gitnexus/test/fixtures/` is listed in the repo-root `.prettierignore` — running prettier from inside `gitnexus/` does not pick that file up and normalizes the tab away. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqnsJK3Cnbu3bjdZbzgMMP * fix(resolution): resolve qualified construction callees (#2708) `new ns.Service().doWork()` emitted only the construction edge. The call branch splits the callee at its last `.` before construction is considered, so a qualified type name was routed into `obj.method()` resolution as if `ns` were a receiver and `Service` a member. A keyword-marked expression is never a member call, so resolve it as construction before the split. The callee lookup now also handles a dotted name: an unambiguous `qualifiedNames` match first, then the trailing simple name, mirroring how receiver resolution elsewhere in this pass degrades. Measured: before: | viaQualified | Class:src/svc.ts:Service | (construction only) after: | viaQualified | Method:src/svc.ts:Service.doWork#0 | Bare-form qualified construction (Python `models.User(db).save()`) is NOT addressed here: that shape currently emits no edges at all, including no construction edge, so it is a namespace-import resolution gap upstream of this pass rather than a construction-typing one. Tests: `viaQualifiedCtor` added to the typescript-inline-constructor-receiver fixture. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqnsJK3Cnbu3bjdZbzgMMP * fix(java): drop the unreachable constructionSyntax declaration (#2708) Java was wired `{ keyword: 'new' }`, and the PR described it as one of the languages that needed the fix. Measuring both ways shows it never did: Java resolves `new Svc().doWork()` identically with and without the change, because `java/captures.ts` (#2564) already rewrites an `object_creation_expression` receiver to the constructed type's simple name, so the raw `new Svc()` text never reaches this resolver. The decisive evidence is generics: Java resolves `new Box<User>().doWork()`, which the keyword path could not do before the template-argument fix earlier in this series — the resolution demonstrably comes from the capture rewrite, not from here. Removing the declaration rather than leaving it as defensive configuration: an unreachable per-language opt-in reads as coverage that does not exist, and the contract now records why Java is excluded so the omission is not mistaken for an oversight. Verified after removal: the Java probe still resolves both the inline and two-step spellings, and the Java resolver suites pass (252 passed, 1 skipped). An earlier coordinator measurement in this review claimed Java WAS broken on base; that comparison was invalid (the "without fix" build had not been rebuilt). Corrected here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqnsJK3Cnbu3bjdZbzgMMP * refactor(resolution): state the selector rule once and derive its option type (#2708) Two follow-ups from review, no behaviour change (643 resolver tests pass unchanged before and after): The `Class.new` selector rule was written out twice — in the `obj.method()` branch and again in the chain walker — against differently named locals, while the construction helper's own doc comment claimed the rule was stated in exactly one place. Both sites ask the identical question, so they now call one `isConstructionSelectorHop` predicate, and the doc comment says what is actually true. `ResolveCompoundReceiverOptions.constructionSyntax` re-declared the contract's object shape by hand. It was the file's first object-shaped duplicate, and because the value arrives as a non-literal variable, TypeScript's excess property check would not fire: a sub-field added to the contract later would type-check and then be silently ignored here. It is now derived with `ScopeResolver['constructionSyntax']`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqnsJK3Cnbu3bjdZbzgMMP * test(resolution): cover the C# construction path and pin the wiring inventory (#2708) Three coverage gaps from review, no behaviour change. C# had no fixture despite being the only keyword-wired language whose behaviour genuinely depends on the construction rule — measured absent on base and present on head. `csharp-inline-constructor-receiver` covers the inline spelling, the two-step spelling, and a static factory that must keep resolving through its return type rather than being read as construction. The TypeScript two-step assertion checked only `toContain('Service')`, and the same fixture defines `LegacyService` — `'LegacyService'.includes('Service')` is true, so the assertion could not distinguish the two targets. It now pins `targetFilePath` the way its sibling assertions already do. Nothing guarded the deliberate opt-in set, so an accidental wiring of a language that already resolves the shape, or a silent loss of one that needs it, would pass the whole suite. `construction-syntax-wiring.test.ts` pins the inventory in both directions: exactly which languages declare `constructionSyntax` and with which spelling, and that java/php/swift/dart/ kotlin stay unwired. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqnsJK3Cnbu3bjdZbzgMMP * chore(storage): bump INCREMENTAL_SCHEMA_VERSION to 23 for the #2708 edge changes This series changes which CALLS edges are emitted for source whose CONTENT has not changed — inline constructor receivers that previously emitted nothing now resolve, and the Ruby selector fix moves one edge back to the member it always belonged to. That is precisely the class of change the version-history block in this file requires a bump for, and the reuse gate is a strict equality on the persisted stamp. Without it, every existing v22 index passes the gate on the next `analyze` — or is served by the same-commit "already up to date" fast path — and keeps returning the pre-fix graph for unchanged files. `impact(direction: "upstream")` and `context()` would go on omitting the very callers #2708 is about, with no warning, until something unrelated forced a full re-analyze. The fix would have shipped without reaching anyone who already had an index. Precedent is unbroken across the recent resolution PRs: #2723 → v22, #2699 → v21, #2695 → v20, #2563 → v14, each with its own rationale paragraph. This adds v23 in the same form. The pinned assertion in call-summary-schema-version.test.ts moves with it, as that test documents it is designed to. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqnsJK3Cnbu3bjdZbzgMMP * chore(bench): re-baseline the fixture-corpus fingerprints for #2708 Both bench harnesses fingerprint an entire fixture corpus by directory prefix (`bench/python-scope/measure.mjs:38`, `bench/scope-capture/measure.mjs:76`), so every fixture directory this series adds moves a committed baseline. Neither script writes the baseline itself — running without `--check` only prints, and the file is edited deliberately, which is what its own comment asks for. Regenerated, last in the series so the fixture set was final: bench/python-scope/baseline-fingerprint.txt 36e29abc… -> f120df92… bench/scope-capture/baselines.json ruby 070e4e11… -> fea3edf8… typescript 281e9548… -> cad25be9… csharp e05dc274… -> 05a85bae… CI only ever reported the python drift, because the benchmarks job runs the python step first and aborts there; the cross-language step never ran. Both were verified locally after the update: [measure --check] PASS (capture fingerprint + scaling) [import-target-fingerprint --check] PASS (resolver fingerprint) [scope-capture --check] PASS (15 languages) The `csharp` and `ruby` entries moved because of the fixtures added earlier in this series, not the original ones — a reminder that this baseline moves with any fixture addition, not just the one that first triggered it. Captures goldens regenerated alongside (csharp, ruby); both additive only, no existing digest changed. The python golden did not move: no `python-*` fixture was added after its last regeneration. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqnsJK3Cnbu3bjdZbzgMMP * Update tests for passesReuseGate function --------- Co-authored-by: Gergo Magyar <gergomagyar0@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 16:19:53 +01:00
Gergő Magyar	df06529950	fix(rust): resolve module-qualified calls against the module tree (#2730) (#2741) ... * fix(rust): resolve module-qualified calls against the module tree (#2730) A Rust call written with a path (`tools::dispatch(..)`) was captured with only its tail identifier, making it indistinguishable from a bare `dispatch(..)`. The scope-chain walk then resolved the bare name lexically and bound it to whatever `dispatch` was nearest — which, for the common wrapper idiom fn dispatch(..) -> ToolOutcome { tools::dispatch(..) } is the wrapper itself. The graph gained a self-loop, the real cross-module edge never existed, and `impact` reported the callee as unreached: the issue's repository showed its central tool dispatcher as `risk: LOW` with 0 affected processes and both "callers" being `#[cfg(test)]` functions, while still labelling the result `epistemic: "exact"`. Resolve paths the way rustc does, over the module tree rather than the filesystem: - `mod_item` now emits `@declaration.namespace`, so a Rust module is a named definition rather than an anonymous scope region. This mirrors the existing C++ `namespace_definition` capture and lets the shared `tagNamespacePrefixes` pass stamp members with their enclosing module path — that pass needed no changes to start working for Rust. - `module-path.ts` reconstructs the other half of the tree: crate roots are directories holding `main.rs`/`lib.rs`, and a file's module path is its location below that root. A definition's module is its file's module plus any enclosing `mod` blocks. - `crate::`, `self::` and `super::` are prefix transforms on the calling module, not reasons to stop resolving. - The final path segment is looked up as a member of the resolved module, including members it only re-exports. A `pub use` creates no binding on the re-exporting module's own scope, so re-exports are followed through that module's import edges. Resolution runs ahead of the implicit-`this` and scope-chain tiers, so an explicit path outranks a lexical shadow, and returns undefined on an unknown module, a missing member or a tie — leaving the existing chain untouched. The new `ScopeResolver.resolveQualifiedFreeCall` hook is optional and unset for every other language, so this is additive. Fixes the reported case (direct callers 2 -> 3, impacted 2 -> 6, the Agent module now visible) plus multi-segment paths, `super::` paths and `pub use` facades, each of which previously produced a wrong edge. Known limitation, pre-existing and unchanged by this commit: an inline `mod inner { fn dispatch }` and a crate-root `fn dispatch` in the same file collapse to one graph node, because node identity is `<file>:<qualifiedName>` and does not carry the module path. That is a separate defect requiring module-path-qualified node ids and an incremental-schema migration. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * test(rust): rebaseline the scope-capture fingerprint for the module-tree captures `mod_item` now emits `@declaration.namespace` and scoped call sites carry `@reference.qualified-name`. Both are additive, so every bench fixture holding a `mod` block or a `Foo::bar()` call gains capture groups, and the corpus grew by the three `rust-2730-*` fixtures. Only the Rust fingerprint moves. The other 14 languages are byte-identical, which is the intended blast radius for a language-local capture change. Scaling stays linear at 1.043, well inside the 1.5 budget. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(rust): carry crate identity in qualified module paths (#2741 review H1) A module was identified by its path segments below a crate root, so `crates/alpha/src/tools.rs` and `crates/beta/src/tools.rs` were the same module. A cargo workspace routinely gives several members the same internal module name — `util`, `error`, `config`, `types` are near-universal — and that made qualified resolution do one of two wrong things: - where only one member defined the called name, the call bound ACROSS crates; - where both defined it, the lookup saw two candidates, refused, and handed the site back to the lexical walk that emits the same-name self-loop. The fix for #2730 therefore switched itself off in exactly the workspace layouts it was written for, and #2730's own reported reproduction repository is multi-crate. A module is now `{ crateRoot, segments }` and `sameModule` compares both. Rust has no implicit cross-crate paths — reaching another crate requires naming it — so two modules in different crates are never the same module. Anchored paths (`crate::`, `self::`, `super::`) resolve inside the caller's own crate and inherit its root. Covered by a two-member workspace fixture where both crates define `tools::dispatch` behind a same-name wrapper, plus unit tests for the path arithmetic itself, including the branches no fixture reaches (a file under no crate root, a `super::` chain walking above the crate root). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(rust): count only module members when resolving a qualified call (#2741 review H3) Module membership was inferred from the file path alone, so any callable in the right file counted as a member of the module. A `fn` nested inside another `fn` has the same `filePath`, the same bare `qualifiedName` and no owner, making it indistinguishable from a module-level item: pub fn dispatch() -> usize { 3 } // the real member pub fn wrapper() -> usize { fn dispatch() -> usize { 99 } // counted as a second member dispatch() } Two candidates tie, the lookup refuses, and the call falls back to the lexical walk that emits the same-name self-loop — so an unrelated local helper anywhere in a module silently reinstated #2730 for every qualified call into it. The scope model already draws the line exactly: a module-level item is bound with `origin: 'local'` in its module's own scope, a function-local item binds in the enclosing Block, and an `impl`/trait method binds in the Class scope. Membership is now that binding lookup rather than a path comparison. Inline-`mod` members bind in their Namespace scope rather than the file's Module scope, and reaching it would mean walking every child scope — faulting them back in from disk on the out-of-core path. They keep being identified by the `namespacePrefix` the shared tagging pass stamps on them, which a file-module member never carries. The documented residual is a `fn` nested inside a `fn` inside an inline `mod`, which inherits that prefix; that is strictly smaller than before and costs a refusal, never a wrong edge. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(rust): require a use-binding to name a module, not a type (#2741 review H2) Import resolution deliberately strips a trailing symbol segment when probing for a file — "the last segment might be a symbol (function, struct, etc.), not a module. Strip it and try again" (import-resolvers/rust.ts). So `use crate::client::ClientBuilder;` also resolves to `client/mod.rs`. The qualified-call resolver took that at face value and treated the imported TYPE as the module `client`. Rust impl methods carry a bare `qualifiedName`, so `ClientBuilder::new()` was then looked up among `client`'s module members and bound to an unrelated module-level `new` — turning an unresolved site into a false edge, which the module's own contract calls the worse outcome. A binding now has to name the module it resolved to. The edge's `targetExportedName` is the tail of the written path, so comparing it against the resolved module's own tail separates the cases exactly: use crate::tools; tail `tools` module ['tools'] accept use crate:🅰️:b as tools; tail `b` module ['a','b'] accept use crate::tools::{self, Ctx}; tail `tools` module ['tools'] accept use crate::client::ClientBuilder; tail `ClientBuilder` module ['client'] reject Covered by a fixture where `client/mod.rs` deliberately holds both `impl ClientBuilder { fn new }` and a module-level `fn new`, so a regression re-binds to the wrong one, plus a control asserting a genuine `client::new()` module qualifier still resolves. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(rust): give src/bin targets their own crate root (#2741 review) Cargo auto-discovers a binary target for every `src/bin/<name>.rs`. Each is a separate crate with its own `crate::` root, and its submodules live under `src/bin/<name>/`. Only `main.rs` and `lib.rs` established a crate root, so those entry files were folded into the surrounding library and given the invented module path `bin::<name>`. That made `crate::helper()` inside a binary resolve into the LIBRARY's `helper` — and unlike the other findings in this review, this one downgraded an edge the lexical walk had previously resolved correctly, so it made existing output worse rather than merely failing to improve it. `src/bin/<name>.rs` is now its own crate root (as is the `src/bin/<name>/main.rs` directory form), so a binary's modules and the library's modules of the same name are no longer the same module. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(rust): only try a submodule candidate the caller actually declares (#2741 review) The first candidate module was `callerModule ++ qualifier`, yielded before the `use` channel and never checked against anything. That let file layout outrank a real import: with `use crate::b;` in `src/a/mod.rs` and an undeclared — or `cfg`-gated — `src/a/b.rs` present on disk, `b::f()` bound to the sibling file, where rustc resolves it to `crate::b`. A `mod` declaration, inline or file-backed, emits a `Namespace` def bound locally in the declaring scope, so the candidate is now gated on that binding rather than assumed. When the caller does not declare the submodule the candidate is skipped and the `use` and crate-root channels still run, so this only removes guesses. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(rust): follow only real re-exports, and refuse on an ambiguous one (#2741 review) Two problems in the re-export channel. A private `use` was followed as though it re-exported. `use crate::tools::helper;` makes `helper` visible INSIDE the module; it does not put it on the module's public surface, so `facade::helper()` does not compile. Only `pub use` does, and finalize already distinguishes them — `reexport` for `pub use`, `named` for a private one. The `alias` kind is now accepted alongside `reexport`, because `pub use x::y as name` is a re-export that was previously ignored entirely. The lookup also took the first matching edge in file-iteration order, which is parse-pool order. Two `cfg`-exclusive facades re-exporting the same name are indistinguishable at this layer, so picking one baked a coin flip into the graph. It now refuses on a genuine tie, consistent with how member lookup already behaves. The pre-existing limitation that only FILE modules are reachable — a `pub use` inside an inline `mod facade { … }` has no `moduleScopeByFile` entry — is now stated in the code. Reaching those would mean walking every child scope and faulting the scope tree back in from disk, which is the cost that index exists to avoid; a miss falls through to the unchanged chain rather than guessing. The regression test deliberately makes the re-exported name globally ambiguous. Without that, the pre-existing unique-global free-call fallback resolves the call on its own and the assertion passes whatever this channel does. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * perf(rust): stop type-qualified calls paying for module resolution (#2741 review) The capture carrying `rawQualifiedName` matches every `scoped_identifier` callee, so this hook was reached by `Vec::new()`, `String::from()`, `Self::method()` and every other type-qualified call — the overwhelming majority of `::` calls in real Rust, none of which name a module. Each one ran the full candidate search before returning undefined, and every candidate that missed then walked all of `workspaceIndex.moduleScopeByFile`. Total cost grew as `qualified-call-sites x files`; two independent measurements put per-site cost at 0.117 -> 0.428 ms across 301 -> 1201 files, i.e. linear in workspace size. Two changes: - The module index now carries a flat set of every module segment name in the workspace, and a qualifier whose head matches none of them is rejected before any candidate work. Measured at 0.02 us per rejected call and flat in file count (500 -> 8000 files), against a previously linear per-site cost. - Module scopes are indexed by module identity once per pass rather than rediscovered by scanning every file per candidate. On the out-of-core scope index that scan was worse than CPU: `moduleScopeByFile` fetches through `scopeTree.getScope`, so a full sweep could fault every module scope back in from disk — the pattern `workspace-index.ts` added `exportedCallableByName` to avoid. Given the #2649 and #1871 history this mattered before merge. The captures golden is regenerated for the fixture files added earlier in this series; `emitRustScopeCaptures` itself is unchanged by this commit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(storage): bump schema versions so the #2730 fix reaches existing indexes Neither invalidation constant was bumped, so the fix did not reach the users who reported the bug. `INCREMENTAL_SCHEMA_VERSION` 22 -> 23. The incremental write set only covers CHANGED files, so a top-up against a pre-v23 index keeps the wrong self-loop — and keeps reporting the callee as unreached — for every unchanged Rust file. The constant's own doc block states this rule, and the precedent is exact: v11 is the same file (`rust/query.ts`) gaining a capture that changes CALLS edges, with the same "force a full re-analyze" contract, and v12 is a second Rust instance. `SCHEMA_BUMP` 30 -> 31. `@declaration.namespace` and `@reference.qualified-name` are parse-time captures, so a warm parse cache replays the old capture set verbatim: `rawQualifiedName` comes back undefined and no Namespace def exists to hang a module prefix on, turning the entire resolution tier into a no-op on unchanged files. `PARSE_CACHE_VERSION` folds in the package version, so a tagged release would have invalidated eventually — but source, dev and CI builds at the same version would not, and the v29 note already warns that relying on someone else's bump is how a change ships with no invalidation at all. Re-checked against origin/main at commit time, as that note instructs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(scope-resolution): let a language opt out of the already-namespaced guard (#2741 review) `tagNamespacePrefixes` skips a def whose `qualifiedName` already equals, or is prefixed by, its enclosing namespace path. That is right for C++ and C#, where the qualified name genuinely carries the namespace. Rust qualified names never do, so the guard fired on a coincidence: in `mod a { pub fn a() }` the member's name equals its module's name, the prefix was skipped, and `moduleOfDef` then reported the member as belonging to the PARENT module. `crate:🅰️:a()` refused, and the def became indistinguishable from a crate-root `fn a` for the module matcher. The guard is now conditional on a `qualifiedNamesCarryNamespace` option that defaults to the existing behaviour, and Rust opts out. The shared pass stays language-neutral — the decision lives with the provider that knows what its own qualified names contain. C++ and C# resolver suites pass unchanged alongside the Rust ones (600 tests). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(rust): refuse a leading :: path instead of reading it as relative (#2741 review) A leading `::` anchors at the extern prelude: `::tools::dispatch()` names the CRATE `tools`, not a module of the current one. The path split filtered the empty leading segment away, which silently reinterpreted the path as relative and let it resolve against a local module that happens to share the name. Extern crates are outside the workspace module tree, so the qualified tier now refuses and leaves the site to the unchanged chain. The regression test asserts the tier does not bind into the local `tools` module, rather than asserting no edge at all: the lexical tier still resolves the bare tail on its own, and that behaviour is not what this change governs. Asserting an empty edge list would have been testing a different tier. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * refactor(rust): reuse the canonical callable predicate and drop dead re-exports (#2741 review) `CALLABLE_TYPES` was a local copy of the set behind `isOverloadableCallable` in `utils/callable-labels.ts`. Two copies of the same set drift: extending the canonical one with a new callable kind would silently leave qualified calls of that kind unresolved here, with nothing to catch it. Use the shared predicate. The trailing `export { moduleOfFile, moduleOfDef }` and `export type { ScopeResolutionIndexes }` were commented as being "for the resolver's unit tests". No test imports them: the only importer of this module anywhere in src or test is `rust/scope-resolver.ts`, which takes just `resolveRustQualifiedFreeCall`. Both functions are already exported from `module-path.ts` (where the new unit tests take them from), and `ScopeResolutionIndexes` is canonically exported from `model/scope-resolution-indexes.ts`. Removed rather than left as surface that implies a contract it does not have. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * test(rust): rebaseline the scope-capture fingerprint with the correct prior hash The rebaseline note added with the original fix cited `Prior 655aed01…`, which was two rebaselines stale — it predates both #2604 and #2714. The true pre-PR value on the base commit is `7f1240b3…`. CI could not catch it: the gate compares the live fingerprint against the stored one and never reads the prose, so the audit chain these notes exist to provide was broken with nothing to flag it. The note now carries the correct prior value, and the fingerprint is regenerated for the fixtures this review series added. Scaling 1.061, well inside the 1.5 budget; fixture_count 196; the other 14 languages remain byte-identical. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * test: move the schema-version pin to 23 `call-summary-schema-version.test.ts` asserts the exact value of `INCREMENTAL_SCHEMA_VERSION` and enumerates which stamped versions the incremental reuse gate accepts. It moves with every bump by design — that pin is what stops an id- or edge-changing commit shipping without invalidation. Updated for the bump to 23, with the pre-v23 case added to the reuse-gate table: a v22 index predates Rust module-qualified call resolution, so every unchanged Rust file would keep the same-name self-loop and keep reporting the real callee as unreached. Caught by CI rather than locally, because the earlier sweeps in this series covered `test/integration/resolvers/` and `test/unit/scope-resolution/` only — the pin lives outside both. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV --------- Co-authored-by: Gergo Magyar <gergomagyar0@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 13:41:47 +01:00
azizur100389	79ff44dfa9	fix(config): honor parts negation on Windows (#2720) ... Normalize repository-relative paths before applying ignore-package rules so `.gitnexusignore` negation can override hardcoded `parts` exclusions during Windows traversal. Co-authored-by: Gergő Magyar <gergomagyar@icloud.com>	2026-07-28 20:04:34 +01:00
Void Freud	7be6d29ca0	fix: require repo in multi-repo MCP tool schemas (#2717) ... * fix: require repo in multi-repo MCP schemas * style(mcp): fix server test formatting * chore(autofix): apply prettier + eslint fixes via /autofix command * test(mcp): cover repository schema policy --------- Co-authored-by: Gergő Magyar <gergomagyar@icloud.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>	2026-07-28 20:04:04 +01:00
Abhigyan Patwari	ee9987fdc5	Merge pull request #2719 from voidfreud/fix/configurable-embedding-timeout ... fix: allow slower remote embedding responses	2026-07-29 03:46:37 +09:00
Gergő Magyar	89ea233e10	fix(js): index CommonJS exports.foo = function () {} exports (#2723) (#2729) ... * fix(js): index CommonJS `exports.foo = function () {}` exports (#2723) Functions assigned to an `exports` / `module.exports` property were not indexed at all. On a CommonJS codebase — the dominant pre-ESM Node style (Express, Firebase Functions) — the graph held every internal helper and missed the entire public API: `impact({target: 'areVariablesValid'})` answered `Target not found` for the one symbol whose blast radius mattered. The gap had two halves, and fixing either alone leaves the feature broken: 1. `tree-sitter-queries.ts` carried `@definition.function` rules for every declaration form and every variable-binding closure form, but none for `assignment_expression` — so no `Function` node was created. 2. The scope-resolution queries (`languages/{javascript,typescript}/query.ts`) likewise had no `@declaration.function` for the shape. Adding only (1) moves `impact` from "not found" to "found, zero callers", because call resolution reaches a definition through the scope declaration, not through the graph node. Both layers now carry the rule, for `function` / `async function` / arrow / async arrow / generator right-hand sides, in JavaScript and TypeScript. The receiver is pinned to `exports` / `module.exports` with `#eq?` predicates: the general `X.foo = function () {}` shape also covers `Foo.prototype.bar` and `this.handler`, which are member constructs with their own ownership questions, and a broader rule would emit ownerless top-level Functions for them. The declaration binds the bare property name into the module scope, which is what importers see, so `const { foo } = require('./m')` matches by name and a namespace `m.foo()` walks the module's defs. Verified end to end: node emission for every listed form plus TS parity, and CALLS edges for same-file `exports.foo()`, cross-file namespace `m.foo()`, and cross-file destructured `require()`. The generator call-resolution case was confirmed to fail against the pre-fix build before the rule landed. Fixes #2723 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(js): stop the CJS export rule from shadowing a declared function (#2723) Review of the previous commit caught a regression it introduced. The CJS `@declaration.function` rules bind the exported property name into the module scope — which is the point, since that is what importers resolve against. But when the file ALSO declares that name lexically: function dup(v) { return v; } exports.dup = function (v) { return !v; }; function callIt(v) { return dup(v); } the module scope ends up holding two declarations named `dup`, the name is ambiguous, and the resolver drops `callIt -> dup` entirely — an edge that resolved fine before #2723. Confirmed by rebuilding both states: present at ff86ccf1e, missing at f302916c. A silently missing caller is worse than the gap #2723 set out to close; it is the impact-under-reporting class this repo has been bitten by before. The emitter now drops the CJS `@declaration.function` in exactly that case. The lexical declaration already supplies the module-scope name, so importers still resolve through it and intra-module resolution returns to its pre-#2723 behavior — verified by re-running the probe that found the regression. Implemented at the established seam: a shared pure helper both capture emitters import and apply at the existing `@declaration.function` filter, mirroring `array-callback.ts` (#1876), which solves the same "drop a spurious declaration emit-side" problem. The module-scope name set is computed once per file and memoized per program root in a WeakMap, rather than walked per export — a 1000-export CommonJS module is precisely the shape #2723 was reported against, and the per-export walk would be quadratic there. `tree.rootNode` was probed to confirm it returns a stable object identity, so the memo actually hits; measured scaling across 250/500/1000/2000 exports is linear. Only the scope declaration is suppressed. The graph node comes from a separate query and collapses onto the lexical declaration's node by name, so no node is lost. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * perf(js): fold the CJS export RHS forms into one pattern per receiver Benchmarking the #2723 rules found the only reproducible cost is tree-sitter query COMPILE, paid once per worker process when the lazy Query singleton is built. Steady-state per-file emit cost and memory proved to sit below the measurement noise floor, so there is nothing to win there. The six CJS scope-query patterns per language (3 right-hand-side forms x 2 receiver forms) collapse to two, folding the RHS forms into an inner leaf alternation. Measured over 5 runs per build, variance under 1ms: query compile base before after JavaScript 42.2ms 50.6ms 45.1ms TypeScript 116.5ms 136.4ms 123.3ms That recovers ~65% of the added compile cost in both grammars — about 19ms per worker process, so ~75ms on a 4-worker analyze — and removes 45 lines of duplicated query text. The alternation is deliberately the INNER LEAF form. tree-sitter 0.21.1 has a known hazard where a top-level `[...]` alternation makes sibling branches share a single predicate bucket, silently dropping matches with no compile error (it has bitten this repo twice: #1904, #1912). Here every predicate sits on a capture OUTSIDE the alternation — `@_cjs.exports` / `@_cjs.module` are on the left-hand side and bound in every branch — which is the documented safe shape. Verified rather than assumed: a probe asserts all six receiver x RHS combinations still bind both `@declaration.function` and `@declaration.name` in both grammars, and that `exportz.x` / `module.other` / `Foo.prototype.bar` / `this.handler` / aliased `exports` are still rejected — 26/26 checks, so the predicate bucket is intact. No behavior change: the graph output on a 600-file corpus is identical node-for-node and edge-for-edge, and the 142 JS/TS integration tests plus 1299 scope-resolution unit tests are unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(js): index prototype and `this` member assignments as Methods (#2723) Follow-up on the known limitations listed with the CJS export fix. Three of them close here; the rest are recorded below with what they actually cost. `Foo.prototype.bar = function () {}` is the dominant pre-ES6 method form — the same population as the CJS exports this PR started with — and it was equally invisible: no node at all, so `impact` could not reach a single prototype method. `this.handler = function () {}` inside a constructor is its sibling, and the pre-ES6 form of the closure-valued class field #2693 already models as a Method. Both now emit a `Method` with an owner edge: function Foo() {} Foo.prototype.bar = function (v) { return v; }; // Method:f.js:Foo.bar, HAS_METHOD Function:f.js:Foo -> Method:f.js:Foo.bar The label comes from `provider.labelOverride` (Function -> Method) and the owner from a sibling of `findObjectLiteralBindingInfo` — the helper that already answers "this Method's owner is named by syntax, not by an enclosing container" for object-literal methods. No new shared-code seam was invented. Ownership resolves to what the file actually declares, so the edge points at a node that exists: `function Foo` gives a `Function` owner, `class Foo` a `Class` owner, and an owner the file does not declare (`External.prototype.x = …`) claims NO owner edge rather than one pointing at a fabricated node. A `this.x = fn` inside a class constructor needs none of this — parse-worker resolves its owner from the enclosing class first. Member ids qualify by owner (`Method:f.js:Foo.bar`). Without that, two constructors in one file that each define `bar` collapse onto a single `Method:f.js:bar` — the same identity collapse #2699 fixed for function-local callables. Only the new prototype/`this` path qualifies, so object-literal method ids are byte-identical to before. Third fix, the orphan twin: `class Dup {}` plus `exports.Dup = function () {}` emitted `Class:f:Dup` AND an unreachable `Function:f:Dup`. The scope declaration for a shadowed CJS export is suppressed (previous commit), so the node had nothing that could resolve to it; with a `function` of that name the node collapsed by id anyway, but with a `class` the labels differ so it lingered. `labelOverride` now returns null for that case and no node is emitted. ## Still open, with measured cost - Receiver-typed CALLS to a prototype method (`f.bar()`) do not resolve yet. A class method resolves because the class owns a scope the resolver attaches members to; a prototype assignment has no such scope, so this needs the scope layer to associate members with the constructor's type. Verified as a control that `new KlassC().meth()` does resolve, so this is specifically the missing half, not a general gap. - `exports.fwd = lib.imported` still does not forward to the original definition — resolution/finalize-layer aliasing, reachable by no query rule. Note `exports.localFn = localFn` (declare-then-export, by far the more common idiom) ALREADY resolves and needed no work. - Aliased `const e = exports; e.foo = fn` and module-top-level `this.x = fn` remain unindexed. The latter is only an export under CommonJS semantics; in ESM top-level `this` is undefined, so it needs a CJS gate rather than being applied to every `.js` file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(js): index CJS exports assigned through an alias (#2723) `const e = exports; e.foo = function () {}` exports `foo` exactly as `exports.foo = fn` does, but no query can express "an identifier that happens to alias the exports object" — the receiver is only knowable per file. So the member-assignment rules now match ANY identifier receiver and the emitters classify. A file's module-scope aliases (`const e = exports`, `const m = module.exports`) are collected once per program root and memoized beside the declared-name set, so the answer costs one top-level pass no matter how many assignments ask. The widening is only safe because the pruning is exact, and that is the risk worth stating plainly: without it every `obj.handler = function () {}` in every JS/TS file would emit a spurious top-level `Function` named `handler`. Both layers prune: - graph nodes, in `labelOverride`: an assignment-anchored capture that is not a recognised shape returns null, so no node is emitted at all; - scope declarations, in both capture emitters: a receiver that is not the exports object declares nothing at module scope. Verified on both sides. `obj.notAnExport`, `self.alsoNot` and `localThing.nope` produce no node and no declaration, while an aliased export resolves cross-file through both the namespace and destructured `require()` forms. ## Cost Re-benchmarked, because this widens a query the previous commit had just optimized. Query compile over 3 runs: JavaScript 46.5ms, TypeScript 123.8ms — +1.4ms and +0.5ms against the optimized state, since dropping the `#eq?` predicates offsets the added patterns. Steady state on the assignment-heavy corpus (200 files x 30 member assignments, the worst case for a widened receiver) stays inside the +-4% noise band established earlier. Heap unchanged. One measurement artifact worth recording so it is not mistaken for a regression later: the real-repo TS corpus went 93,586 -> 93,748 captures across these commits. That is corpus drift, not over-matching — the benchmark walks a sorted file list and takes the first 400, and this work added a new source file to that tree. The repo's own TypeScript contains zero occurrences of the `identifier.property = function` shape, so the widened rule contributes nothing there. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(js): treat module-level `this.X = fn` as a CommonJS export (#2723) In CommonJS, module-level `this` IS `module.exports`, so this.handler = function (data) { … }; at the top of a `.js` file exports `handler` exactly as `exports.handler` does. It previously produced an ownerless `Method` that no importer could reach. The CommonJS gate is the whole point of the change, not a detail. Top-level `this` is `undefined` in ESM, so the same line exports nothing there — treating it as an export would mis-index every `.mjs`, every `"type": "module"` package, and every `.ts` that compiles to ESM. Detection is deliberately asymmetric: an `import`/`export` statement settles the file as ESM immediately, a `require()` call or an `exports`/`module` reference marks it CommonJS, and a file carrying NEITHER signal is left alone — silence is not evidence of CommonJS. `this` nesting follows the receiver rule the scope queries already encode (#2701): an arrow does not bind `this`, so a top-level arrow's `this` is still the module's and passes through the walk, while every other function form binds its own receiver and stops it — that is an instance member, which keeps the Method-plus-owner treatment from the previous commit. Verified across all three cases rather than just the happy path: a CJS file exports both the `function` and arrow forms and they resolve through a cross-file destructured `require()`; an ESM file's identical line produces no export; and a file with no module-system signal produces none either. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(js): forward CJS re-exports to the original definition (#2723) Last of the known limitations. `exports.fwd = lib.imported` assigns an EXISTING symbol rather than a function literal, so no definition rule reaches it and importers of `fwd` resolved to nothing: const lib = require('./lib'); exports.forwarded = lib.imported; // via a namespace binding const { second } = require('./lib'); exports.alsoForwarded = second; // via a named binding Both forms are now synthesized as re-export markers in the same post-query pass that already decomposes `require()`, reusing the decomposer's existing vocabulary rather than adding a case to it. The kind is the whole fix, and it was established by measurement, not by reading. Emitted first as `named-alias` — the shape the destructured `require()` form uses — the forwarding still did not resolve: an import binding is PRIVATE to its module, exactly as in ESM, where `import { X }` does not re-export X. `reexport-alias` (`export { X as Y } from './m'`) is what a CJS forwarding assignment actually is, and with it the call resolves through the forwarding module to the original definition. `exports.foo = localFn`, where the right-hand side is a locally DECLARED function, is deliberately not handled here: the module scope already binds `localFn`, importers already resolve through it (verified before writing any code), and synthesizing a second binding would re-create the ambiguity the shadow guard exists to prevent. JavaScript only, matching where CJS `require()` decomposition already lives — `typescript/captures.ts` has no require pass at all, since a `.ts` file using CJS forwarding is vanishingly rare next to the cost of a second implementation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(js): document the CommonJS export surface now that #2723 closed it The known-limitation note still described `exports.X` as unmodeled and listed the re-export edge as missing. Both are stale: the note now states which forms declare a module-scope name, which two cases are deliberate non-cases (a locally declared value needs no second binding; a name the module also declares lexically is suppressed rather than made ambiguous), and that member assignments through a receiver are Methods with an owner edge. `module.exports = fn` — an anonymous default with no name to bind — remains the one genuine limitation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(js): index the CommonJS default export `module.exports = fn` (#2723) The last documented limitation. `module.exports = function () {}` exports the whole module as a callable, so there is no property to take a name from and nothing declared it. Named after the file by `deriveDefaultExportHocName` — the convention this repo already applies to anonymous default exports — so `index.js` takes its parent directory. A NAMED function expression keeps its own name instead, which is more informative than the file. Two traps, both found by probing rather than reading: - The widened member-assignment rule already matches this shape, capturing the LEFT property as the name — the literal `exports`. Left alone it produced `Function:<file>:exports`, and for a named function expression a SECOND node beside the real one. The worker now overrides the captured name for this shape, which is why it takes precedence over `nameNode`. - `labelOverride` was suppressing the node entirely. That is the widening's safety net working as designed — an assignment-anchored capture that is not a recognised shape emits nothing — and this was simply a shape it had not been taught. The scope declaration is synthesized in the capture emitter rather than the query, because a tree-sitter pattern has no access to the file path the anonymous name derives from. Without it the node would exist with nothing resolving to it, the half-fixed state this issue already had to correct once. `exports = fn` is deliberately NOT indexed, and there is a test pinning that: reassigning the `exports` binding does not export anything in CommonJS, it only breaks the alias to `module.exports`, so indexing it would invent an export that does not exist. ## Limit worth knowing `const m = require('./mod'); m()` resolves only when the local binding name matches the derived name — a naming coincidence, not a mechanism. Resolving a renamed binding (`const renamed = require('./mod'); renamed()`) needs the finalize layer to treat a called namespace binding as the target module's default export, which is separate work. The node itself is always emitted, so `impact` / `context` / `rename` reach it either way — which is what #2723 asked for. Adjacent gap found while measuring, NOT addressed here: ESM `export default function () {}` (anonymous) is equally unindexed. Same class, different construct, and widening to it would change behaviour for files this issue never touched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(js): record module.exports = fn and the two remaining default-export gaps The note still listed `module.exports = fn` as unmodeled. It is indexed now; what remains is narrower and worth stating precisely: resolving a CALL through a RENAMED default-export binding needs finalize-layer work, and anonymous ESM `export default function () {}` is unindexed for the same underlying reason but is a different construct. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(js): close every finding from the #2729 tri-review A 15-lane review (Claude swarm + ce personas, Codex gpt-5.6-sol swarm + ce + adversarial) ran the real pipeline against both this branch and its base and diffed the graphs. On canonical CommonJS shapes the branch was DELETING call edges that existed at base and FABRICATING edges present in no source. A fabricated edge is worse than the gap #2723 set out to close: it hands `impact` a caller that does not exist. Almost all of it reduced to two root causes. **1. The exports receiver was identified by TEXT, with no scope lookup.** The canonical UMD wrapper takes the exports object as a PARAMETER: (function (exports) { exports.publicApi = function () {}; })(this); A text match called that a module export, invented a symbol, and — because the invented name then collided with module scope — deleted the factory's real call edges. The same blindness made `const helper = require('./helper'); exports.helper = fn` resolve an importer into a DIFFERENT module's function. Receivers (and aliases) are now rejected where a parameter or enclosing local shadows them. **2. The shadow guard reached one of four export forms.** It was wrong in four distinct ways: it never fired for an aliased receiver (`root` was not forwarded), for module-level `this`, or for the default export — each dropping a real edge, and the default-export case merging two functions onto one node so the inner call resolved to itself. And it fired when it should NOT have, deleting a genuine export whose name merely collided with a non-callable variable: let cache = null; exports.cache = function (v) { cache = v; return cache; }; There is now one entry point (`cjsExportedName`) covering direct, alias, `this` and default forms, comparing against CALLABLE declarations only. Also fixed: - Prototype owners bound to variables. `var Foo = function () {}` is the dominant pre-ES6 constructor — the population this work targets — and owner lookup handled only declarations, so two same-named members collapsed onto one unqualified node with no owner edges at all. - TypeScript parity: the default/re-export declaration synthesis lived only in the JavaScript emitter, so a `.ts` file emitted the node with nothing declaring it. Extracted to a shared module used by both. - Module-level `this.X = fn` in ESM or a no-signal file no longer mints an ownerless `Method`; `.cjs`/`.cts` and `.mjs`/`.mts` are now positive module-system signals where the file path is available. - The MCP graph-schema resource documented HAS_METHOD as Class-owned only, while this work adds Function (constructor) owners. - Two dead exports removed; an orphaned JSDoc reattached to the function it describes. - Tests: the `exports = fn` negative test passed trivially (no JS/TS query matches a bare-identifier LHS at all, so it would pass with every guard deleted) — it now carries a positive control in the same fixture. A bounds-y `.some(...)` assertion was replaced per DoD.md:82. Six regressions added, each confirmed failing against the pre-fix build. **Schema constants bumped LAST, deliberately.** `INCREMENTAL_SCHEMA_VERSION` 20->21 and parse-cache `SCHEMA_BUMP` 28->29, with the pin and reuse-gate tests updated. This change alters what is emitted for source whose content has not changed, so without the bump an existing index keeps serving the pre-fix graph for every unchanged CommonJS file — breaching DoD.md:61. Bumping it BEFORE the correctness fixes would have been worse: it would have propagated the fabricated and deleted edges to every index on upgrade. One review finding was withdrawn rather than fixed: a claimed O(n^2) memo failure did not survive verification. Clean production-shaped measurement (fresh parse per file, no instrumentation) shows linear scaling — 0.355, 0.221, 0.216, 0.212 ms/declaration at N=500/1000/2000/4000. The earlier "reproduction" was an artifact of replacing `globalThis.WeakMap` to count misses, which perturbs the identity semantics under test. Verified: 1469 tests across 89 files, including the full scope-resolution unit suite, the JS/TS resolver suites, closure-binding labels, const-function-twin and the pipeline golden. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Gergo Magyar <gergomagyar0@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 19:45:01 +01:00