sync from remote upstream - #3

…ones, and keep the name match for types and interfaces go/types does not compare (#2483)

…2560

fix(ts): resolve a namespace member only through what the barrel exports

… its class (#2527)

…so an external test package's never hides the predeclared one from the package beside it (#2483)

…terfaces-2483

feat(cli): ship the real-time watcher as cgr watch

…terfaces-2483

…sync (#2441)

…onar S107 (#2527)

…esolves to every build's declaration, and a pair that holds in one build alone stays heuristic (#2483)

…terfaces-2483

…ock (#2441)

…-2531

perf(incremental): keep the callers' edges when an edit leaves the file's interface unchanged

…ugh an embed to its caller's builds, rename every build's declaration, and read deep build lines without recursion (#2483)

…sync (#2441)

…ock (#2441)

…terfaces-2483

…2527

feat(dead-code): add --no-public-roots so unused public application code is reported

fix(sync): wait out a killed holder's lock release before refusing a sync

…parser fingerprint (#2634)

…ants, oracle neighbours (#2483)

…terfaces-2483

…parser fingerprint (#2634)

…wers only after a timeout (#2634)

The #897 check appended a separator to every root_path before testing
whether a shared node lies under it. A project indexed at `/` or `C:\`
became `//` or `C:/`+`/`, so nothing matched and a sync purged the
Folder/File nodes it shared with a nested project (Greptile, this PR).
A root that already ends in the separator is now used as is.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01V3cKMds1sLPbFjo8TCJkwg

The detector read each immediate parent's tree from coalesce(root_path,
absolute_path). A Package records its directory as its absolute_path,
so a File two projects reach through their Packages read as inside
both, the rootless Project behind one of them was never seen, and the
purge that counts that owner as legacy never ran (CodeRabbit, this PR).

The single-hop test stays as the cheap per-sync filter; its candidates
are now walked up to their Projects and judged by the same clause the
cross-root purge uses, so the two cannot disagree. The purge itself is
unchanged.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01V3cKMds1sLPbFjo8TCJkwg

feat!: make an embedded SQLite graph the default backend

Since 0.2.0 the graph is an embedded SQLite file by default and Memgraph
is opt-in, but the README's intro, parser description, demo alt text and
pipeline diagram still said the graph lives in Memgraph. They now name
the graph generically, one sentence after the diagram states the default
and the opt-in backends, and the Architecture list links Graph Backends.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015q8BXoMMibpqwdet5XqbS7

PyPI's page for 0.2.0 still listed Docker and cmake as prerequisites,
started the quick start with `cgr daemon up`, titled the SDK example
"Query Memgraph with Cypher" and documented only the MEMGRAPH_* settings.
Docker and cmake are now listed as Memgraph-only, the quick start parses
and queries the embedded graph, the Memgraph steps follow as the opt-in,
the SDK section says MemgraphIngestor follows GRAPH_BACKEND, and the
settings table adds GRAPH_BACKEND and SQLITE_GRAPH_PATH.

The quick start also stops claiming that `--update-graph` opens the chat
afterwards (it syncs and exits) and drops `--clean`, which deletes every
project in the shared graph.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015q8BXoMMibpqwdet5XqbS7

The generator fills each dependency's line with its PyPI summary. When
#3377 merged, cgr-graph-rs was not on PyPI yet, so its line was written
bare. The v0.2.0 release published it with a summary, and since then
test_generated_docs_are_current fails on every branch because the
committed line no longer matches what the generator writes. This is that
generator's output.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015q8BXoMMibpqwdet5XqbS7

…ec7l

docs: describe the embedded graph, not Memgraph, as the READMEs' backend

…t in bash

test_label_lookups_follow_mains_first_parent_line_only timed out on
Windows on main (Unit Tests windows-latest py3.12, shard 1/2, run
38703722345): `bash ./step.sh` exceeded its 15 s subprocess timeout.

The time went to the test's own `gh` stub. For the compare API it
looped over every commit in RANGE, running `cat` twice in command
substitutions and `jq` once, and on Windows each `jq` also went
through the CRLF wrapper's pipe to `tr`. With a 52-commit range that
was 321 process starts and 184 program launches (106 cat, 58 jq,
counted under strace on Linux). Git Bash makes every start cost tens
of milliseconds, more under `pytest -n auto`, so the step sat at the
timeout and failed on a slow runner.

The test now writes the compare output once, in Python, from the same
`messages/` and `parents/` files and the same rules (a commit without
a parents entry takes the one before it; an empty parent is null),
and the stub just `cat`s it. The output is byte-identical to the old
loop's. The same step now starts 61 processes and launches 27
programs. The workflow under test, the env it sees and the timeout are
unchanged.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015q8BXoMMibpqwdet5XqbS7

…ec7l

test(release): build the fake compare output in Python, not per commit in bash

…olders-2665

fix(graph): delete and count only what a project owns when a directory is indexed twice

…hared-structure-3025

Resolve the cypher_queries.py conflict with #2680, which tightened the
same #897 detector and cross-project purge through _LEGACY_SHARED. This
branch's cross-root detector and purge cover the same cases (a nested
root, Windows separators, a filesystem root, a rootless owner), so
_LEGACY_SHARED goes. The cross-project purge runs again only while a
legacy constraint is in force, where every shared node was written by
the old key, so it stays unconditional as on this branch.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01V3cKMds1sLPbFjo8TCJkwg

setup-uv restores its cache only on an exact key match, and the key hashed
uv.lock, whose only change in each post-merge version bump is the
code-graph-rag version line. So every bump commit's CI, and every PR not yet
up to date with the latest bump, started with an empty uv cache. Each job
then re-cloned the full history of the git-sourced tree-sitter-c and
tree-sitter-cpp forks (about 100 MB together; uv has no shallow fetch), and
one dropped connection failed the run, as it did for 0.2.2 on macOS
("early EOF" in Install dependencies).

Each cached setup-uv step now hashes a copy of uv.lock without that line,
written to $RUNNER_TEMP by the step before it. The filter is inline rather
than a script so publish.yml and rust-wheels.yml still work when dispatched
for a tag that predates it.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015q8BXoMMibpqwdet5XqbS7

…ec7l

ci: key the uv cache on uv.lock minus the project version

…ucture-3025

fix(graph): the #897 migration no longer purges Folder/File nodes projects share

The ownership walk #2680 added to delete-project and the project stats
queries tested every node of a containment path through a path variable
(`claim = (p)-[...*]->(c)` with `nodes(claim)`). The embedded engine, the
default backend, compiles no path variables, so on it `cgr delete-project`
and `cgr stats` (scoped, or with more than one project) failed with
"unsupported in the embedded graph engine: path variables".

A path that enters no other project's Package, Module or Section runs
through the project's own qualified nodes and shared Folders/Files, and
only CONTAINS_FOLDER/CONTAINS_FILE edges lead to a Folder or File. So the
claim is taken in two plain walks: the project's own units it reaches,
then the Folders and Files reached from the project or one of its units
through those two edge types. The delete's check that another project
still claims a Folder/File walks the same two steps upward.

The shared-directory e2e tests now run on Memgraph and on the embedded
engine, on a file so its walks run in the Rust extension, and a unit test
runs the four queries on the embedded engine without Docker.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01V3cKMds1sLPbFjo8TCJkwg

fix(graph): delete-project and stats run on the embedded engine again

…miss

test_a_name_its_package_declares_is_no_builtin[gotypes] failed on main
(Unit Tests windows-latest py3.12, shard 2/2, run 38765962220) with
PermissionError reading go-helper-runs/<key>.json. The commit under test
only bumped the version; the merge before it passed with the same code.

The go-helper-runs cache is shared by every xdist worker. Two workers that
both miss on the same tree both run the helper and both os.replace their
copy into place. On Windows a file mid-replace cannot be opened, and a file
another worker holds open cannot be replaced, so the reader (as here) or
the second writer fails with PermissionError.

A copy that cannot be read is now a miss (the helper runs again), and a
copy that cannot be published is dropped. Checked by injecting
PermissionError on the read and on the replace: the unfixed fixture fails
with the CI error in both cases, the fixed one passes.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QMHwdsA49vvqJ2bdoKn6ZP

…ish it

Replaces the previous commit's approach, which caught PermissionError and
carried on: that hid the race instead of removing it.

The go-helper-runs cache is shared by every xdist worker. Workers that
missed on the same tree at the same time each ran the helper and each
os.replace'd their copy into place, and Windows refuses to open a file
mid-replace or to replace one held open, so whichever worker came second
failed with PermissionError (run 38765962220).

The check, the helper run and the publish now happen under a FileLock
per cache entry, so one worker runs the helper and the rest wait and
read its copy. Reads and replaces of an entry never overlap.

Checked with a probe that indexes the same tree 24 times on 8 workers,
spaces each worker's publish 3 s apart and enforces Windows' sharing
rules on the cache: main fails 17 of 24 (15 opened mid-replace, the CI
failure; 2 replaced while open) after 8 helper runs; with the lock
24 of 24 pass, twice, after 1 helper run.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QMHwdsA49vvqJ2bdoKn6ZP

test(go): run the helper once per tree under a lock, not race to publish it