@magic-peach is attempting to deploy a commit to the shashankss1205's projects Team on Vercel.

A member of the Team first needs to authorize it.

👋 Thanks for contributing to CodeGraphContext! Since this PR was opened, main has moved forward significantly (we just shipped v0.5.2 and merged ~50 PRs), so this one now has merge conflicts. Could you please rebase onto the latest main and resolve the conflicts? Once it is conflict-free and CI is green, we will review and merge it. Really appreciate your work — thank you! 🙏

Triage update: this bundles five features (GitHub integration, visualization, security scanning, profiling, custom rules) into one +2k-line PR, which we can't review responsibly as a unit. @magic-peach if any of these is still something you want to land, please split it into one PR per feature against current main — the security scanning piece overlaps with #1313 which we're actively interested in. Thanks for understanding! 🙏

Keeping this open, but it needs splitting before it can be reviewed.

The PR bundles five unrelated capabilities in one changeset — GitHub integration, code visualization, security scanning, performance profiling and custom rules (+2053/-125 across 9 files). Each is a separate design decision, and a reviewer has to accept or reject all five together. That is the main reason this has sat for 156 days.

It is also currently conflicting with main, which has moved a long way since February.

What would make this land. Split into one PR per capability, smallest first, each with its own issue. Two of the five have a clear path right now:

• Security scanning — security: secrets and API keys inside indexed source code stored verbatim in graph DB #1313 is the properly-scoped version (secrets stored verbatim as graph node properties, with entropy/regex detection and CGC_REDACT_SECRETS). A PR against that issue alone would be reviewable.
• Performance profiling — note that codegraphcontext analyze complexity already exists (README.md:525). feat: codegraphcontext analyze complexity threshold flag has no documented output format and no machine-readable export — CI integration is impossible without parseable output #1333 asks for machine-readable output from it, which is a small, concrete target.

For the other three, please open an issue describing the design first — particularly GitHub integration, which spans OAuth, repository import, commit history and PR tracking; those are four separate projects.

I reopened #662 earlier because closing it while this PR was open was the wrong call. The issue stands; this PR just needs to arrive in pieces a reviewer can act on.

Thanks for the substantial work here, and apologies this has been open so long. I attempted the merge and hit 22 conflict regions across server.py and tool_definitions.py, several of them 200-300 lines — both files have been largely rewritten on main since February, so this needs a real rebase rather than a conflict resolution.

Before you spend that effort, though, I'd like to suggest restructuring, because the bundle has partly been overtaken:

This PR carries five independent features (github_integration.py, security_handlers.py, performance_handlers.py, visualization_handlers.py, custom_rules_handlers.py). Two of them now overlap with work already on main:

• GitHub integration — main has a PR Reviewer (website/src/components/PRReviewer.tsx, the /pr-reviewer/:owner/:repo/pull/:prNumber route and the PR code-graph GitHub Action). Worth checking what your github_handlers.py adds beyond it.
• Security scanning — feat: implement secret scanner, redaction utility, and update docs #1313 #1321 just landed a secret scanner (utils/secret_scanner.py) with opt-in redaction at index time. Your security_handlers.py may overlap or may be complementary; I can't tell from a conflicted tree.

My suggestion: split this into one PR per feature against current main, starting with whichever is least overlapping — custom_rules_handlers.py and performance_handlers.py look the most independent. Each will be small enough to review properly and won't rot waiting on the others. A 2000-line five-feature PR is very hard to land, which is largely why it's been stuck.

The new handler modules themselves merge cleanly — it's only the server.py registration and the tool_definitions.py entries that conflict, and those are mechanical to re-add once the branch is rebased.

Let me know which piece you'd like to start with and I'll make sure it gets a fast review. If you'd rather not carry this forward, that's completely fine too — just say so and I'll close it with credit noted on #662.