Source walkthrough
Graphify-Jev: from a question to candidate code nodes
Study this project if you are building code navigation over known candidates. Code builds and traverses a graph; Jev narrows the search. The useful pattern is that division of work, with explicit limits on what a chosen node proves.
1. Follow the input, question and code branch
Start at pick_seeds_with_jev with an existing NetworkX graph and a developer question. Code groups nodes into communities and describes each using file names and high-degree symbols. With several communities, a Choice question selects the relevant scope; the probability distribution can admit a second community, up to two in total.
Within a community with more than two files and more than 35 nodes, another Choice may select a file. Otherwise it proceeds directly to node selection. Node options include location and docstring (or label); when there are more than 40, code keeps the highest-degree 40. A final Choice selects a seed ID for traversal.
This is community → optional file → node, with different call counts by branch. The bridge, pruner and audit modules reviewed here construct Choice questions. They do not establish the Score usage claimed in the older automated summary.
2. A failed selection is not a negative answer
- No key, an empty graph, a failed community request, or community confidence below 0.35 returns None. That lets the caller choose another search path. The 0.35 cutoff belongs to this implementation; it is not a calibrated default for your task.
- If file selection fails, the node stage still considers the community. A failed node request adds no seed; no collected seeds means None. A partial result can therefore cover less than the intended search scope.
- For an architecture audit, a failed request returns diagnosis=UNKNOWN without is_malignant. The scanner then defaults the missing flag to false and places the result in benign_nodes. This is a source-derived failure risk, not an incident reproduced here. Keep unknown separate before treating that list as evidence of health.
3. Read the pruning and cache limits before copying them
The pruner filters some utility names, asks Choice for one neighbor, then fills the remaining slots in candidate order. On failure it returns the first max_keep original neighbors. The retained set is not a full semantic ranking, and a prompt mentioning causality does not verify causal relationships.
The seed cache key uses graph path (or object identity), node count, edge count and normalized query. It does not include a Git commit or content hash. A changed graph with the same counts can reuse old seeds if those IDs still exist; add a content/version fingerprint if your application requires freshness.
Inspect the actual outbound text for your repository. Selection, pruning and audit can include docstrings, in addition to paths and labels. “Only paths and signatures leave the machine” is too strong for this snapshot.
4. Local reproduction: unchanged counts and the 40-candidate boundary
On 2026-11-03 we executed the original _get_cache_key and pick_seeds_with_jev function bodies from this commit, using AST extraction, a synthetic graph interface, mocked clustering and a deterministic Choice stub. The run used CPython 3.9.6 on Darwin arm64 with only the standard library. It made no API calls and read no key or environment files. This was a function-level reproduction, not a Graphify integration or model run.
Cache fixture: two nodes, one edge, one graph path. After swapping the nodes’ docstrings and changing fixture commit metadata, the key remained /fixture/graph.json_2_1::target. The second call reused seed a with zero additional Choice calls. Clearing the cache selected b. The stale result requires surviving node IDs and the same path/object, counts and normalized query; the experiment does not measure how often that occurs in real projects.
Candidate fixture: one community, one file, 40 mutually connected hubs and one isolated target. The target was excluded before Choice saw the 40 candidates. Removing one hub left 40 nodes and exposed the target; the same stub then chose it. This demonstrates a recall boundary even with a chooser that recognizes the target when offered; it does not measure Jev accuracy or the real clustering algorithm.
To repeat, download the public source and script below, then run locally. The Python runner performs no network access and rejects a source file whose SHA-256 differs from the pinned snapshot. The 2026-11-02 source review remains the original baseline; this experiment was added on 2026-11-03.
curl -fsSLo jev_bridge.py https://raw.githubusercontent.com/54lynnn/graphify-jev/85808c6a12ac48a4aa39d149df5f6d8b99f07d37/graphify/jev_bridge.py
curl -fsSLo graphify_offline.py https://jevbooks.com/examples/source-review-2026-11-03-graphify-offline.py
python3 graphify_offline.py jev_bridge.py5. Build the graph before trying the audit
The sequence below follows the pinned README and uses Graphify’s own repository as the target. Use a Python environment compatible with that checkout. Install first, then extract the graph; audit and serve consume that graph. These are documented steps, not commands run by jevbooks.
For a first check without model calls, ensure no key is configured. The client also reads a local .env and ~/.graphify/.env. To test Jev later, configure TYPESAFE_API_KEY and record TYPESAFE_MODEL; an audit with credentials can make API calls.
git clone https://github.com/54Lynnn/graphify-jev.git
cd graphify-jev
git checkout 85808c6a12ac48a4aa39d149df5f6d8b99f07d37
python3 -m venv .venv
. .venv/bin/activate
python -m pip install -e .
graphify-jev extract --code-only .
graphify-jev audit . --json
graphify-jev serve . --port 88996. What would establish that it helps?
- Source verified: the candidate stages, limits, cache fields and failure branches above exist at this commit. This review does not establish that an integration works.
- Author reported: the README describes fast calls and refactoring results. We have not reproduced their latency, diagnosis accuracy or refactoring benefit.
- Still to run: use a small fixed repository; inspect the extracted graph; exercise missing-key and injected request-failure paths; check how UNKNOWN reaches JSON and UI.
- Then compare fixed queries with native search, using human-identified target files/symbols. Save the graph version, actual model, hits, calls, tokens and latency. A low call time alone does not show better navigation.
Use the idea in your own tool
Enumerate legal candidates in code, provide enough text to distinguish them, and return a candidate ID or an explicit unknown. Start with a small set whose correct answer you can check. Copy the separation of responsibilities; choose limits and thresholds from your own evaluation.