Paper ↔ implementation comparison for RPG-Encoder (arXiv:2602.02084) + optional gap notes

Hi RPG-ZeroRepo team — I read the RPG-Encoder paper (arXiv:2602.02084). Really impressive work.

I built a from-scratch implementation because I wanted something I could use immediately in my own workflow across multiple repos, and I made it MCP-ready so it can be plugged into agent/tool setups out of the box.

Repo: https://github.com/userFRM/rpg-encoder (MIT)

If you think it’s useful for others while your official release lands, feel free to link it from here / issues / discussions — totally fine by me.

---

What’s implemented (mapped to the paper at a high level)

RPG graph structure

• Paper: G = (V_H ∪ V_L, E_feat ∪ E_dep)
• Impl: RPGraph, HierarchyNode, Entity, EdgeKind
• Code: rpg-core/src/graph.rs

Phase 1 — Semantic Lifting

• token-aware batching, verb–object feature extraction, file synthesis flow
• Code: rpg-encoder/src/lift.rs, semantic_lifting.rs

Phase 2 — Hierarchy Recovery

• domain discovery + 3-level semantic path assignment
• Code: rpg-encoder/src/hierarchy.rs, prompts/*.md

Phase 3 — Artifact Grounding

• trie-based LCA grounding + AST dependency resolution
• Code: rpg-core/src/lca.rs, rpg-encoder/src/grounding.rs

Evolution / incremental maintenance

• git diff detection + delete/modify/insert application + drift detection
• Code: rpg-encoder/src/evolution.rs

Agent tools described in the paper

• SearchNode: feature/snippet search, auto modes, scope/type/line filters (rpg-nav/src/search.rs)
• FetchNode: fetch entity/hierarchy node + source (rpg-nav/src/fetch.rs)
• ExploreRPG: upstream/downstream BFS, edge/type filtering, depth control (rpg-nav/src/explore.rs)

Paper-specific details

• file-level module entities (V_L): EntityKind::Module, create_module_entities() (rpg-core/src/graph.rs, ~619)
• feature edge materialization (E_feat): materialize_containment_edges() (rpg-core/src/graph.rs, ~698)
• 8 language parsers: Python, Rust, Java, Go, C, C++, JS, TS (rpg-parser/src/)

---

Notes / deltas vs the paper text (kept short)

• Benchmarks / eval: I haven’t reproduced SWE-bench / RepoCraft metrics, and I don’t have your internal evaluation harness/scripts, so I can’t do an apples-to-apples benchmark comparison between implementations.
• Reconstruction traversal export: no explicit “topo-ordered node list” export yet (exports are dot/mermaid, etc.).
• Incremental semantic insertion (Algorithm 3): incremental additions currently land via structural/file-path placement in apply_additions(). Semantic placement is achieved via a full hierarchy rebuild (build_semantic_hierarchy + submit_hierarchy), not per-entity LLM routing during every update.
• Drift judgment: paper mentions LLM-based “intent shift”; this uses a deterministic Jaccard-based drift metric (compute_drift()).

---

Extras (practical additions not in the paper)

• stale graph detection on MCP server startup
• graph backup before destructive ops
• optional zstd compression
• pre-commit hook to auto-update on commit
• rpg-encoder diff preview + rpg-encoder validate integrity checks
• schema versioning + migration (semver)
• search quality benchmarks + npm distribution conveniences

---

If you ever want to use any part of what I built, I’m happy to help however is easiest on your side — I can share a couple tiny sample repos + their expected graph outputs (so you can sanity-check behavior), or split out specific pieces (parsers / grounding / nav tools) if that’s more useful. And if you prefer PRs or just issues, I’ll follow whatever contribution process you use.

One thing I’m curious about: for incremental updates, do you plan to do the paper’s “semantic routing per new entity” (Algorithm 3), or is your intended approach more like “put new stuff in structurally, then rebuild the semantic hierarchy in batches”?

Start by reading the paper alongside the referenced implementation files, including rpg-core/src/graph.rs, rpg-encoder/src/evolution.rs, and rpg-nav/src/search.rs. Verify which listed deltas are relevant to RPG-ZeroRepo and identify the project’s intended incremental-update behavior. Done would require an agreed comparison scope and documented, reproducible findings.