codegraph-rosetta

name

codegraph-rosetta

description

Framework translator for developers landing in an unfamiliar backend codebase. Use when the user knows one framework (e.g. NestJS) and must work in another — Django, Spring Boot, FastAPI, Flask, Go, or Rust — or asks "what's the equivalent of X in Y", "explain this codebase like I'm a NestJS dev", or wants onboarding to a new-to-them stack. Translates concepts (controllers, DI, modules, entities, guards, middleware) between frameworks and maps them onto the actual files in the project.

Codegraph Rosetta — framework translator

Onboard a developer into a codebase written in a framework they don't know, by translating everything into the framework they DO know. Never explain the target framework in the abstract — always anchor every concept to a real file in this project and to its equivalent in the user's home framework.

Workflow

1. Establish the two frameworks.

• Home framework (what the user knows): from their words ("I'm a NestJS dev"), else ask one short question. Default assumption if they've used Contextifly on NestJS projects before: NestJS.
• Target framework (this codebase): detect from marker files, do not ask:

Marker	Target
manage.py, settings.py, INSTALLED_APPS	Django
pom.xml / build.gradle + @SpringBootApplication	Spring Boot
pyproject.toml/requirements*.txt containing fastapi	FastAPI
… containing flask	Flask
go.mod	Go
Cargo.toml (look for axum, actix-web)	Rust
@nestjs/core in package.json	NestJS

2. Load exactly one reference file from references/ for the target framework (django.md, spring-boot.md, fastapi.md, flask.md, go.md, rust.md). It contains the concept-translation table, project-layout guide, and the gotchas list. Do not load the others.

3. Index, then respect what the graph can and cannot see. Run index_project. Check which providers contributed:

• Graph covers the target (NestJS, React/Next.js, Flutter today): use get_project_map, search_graph, trace_flow, get_impact as the skeleton and cite nodes/edges for every structural claim, exactly like codegraph-copilot.
• No provider for the target yet (Django, Spring, FastAPI, Flask, Go, Rust): say so in one line ("no compiler provider for Django yet — this walkthrough is from reading the code directly, not from the verified graph"). Then locate the project's real entry points using the reference file's layout guide and read those specific files. Never present unverified structure with the same confidence as graph-backed structure.

4. Deliver the translation, anchored in this repo. The default deliverable for "help me get into this codebase":

• The map, in home-framework terms — "Django apps orders/, payments/ are what you'd write as NestJS modules; orders/views.py is the controller; orders/services.py is the service layer (this repo does use one — not all Django code does)."
• The mental-model shifts — the 3–5 gotchas from the reference file that actually apply to this repo, each with a file:line example from the project.
• A translated flow walkthrough — take one real request (pick an endpoint that exists here) and narrate it end to end, naming each stage in BOTH frameworks: "request hits urls.py (your route decorator) → OrderViewSet (your controller) → …".
• "If you were writing this in " cheat sheet — for the 5 most common tasks in this repo (add an endpoint, add a model field, add a migration, add a background job, add a test): the home-framework move and the target-framework move, side by side, with the real file paths where each happens here.

For one-off questions ("what's the equivalent of a guard here?"): answer directly from the translation table, show the closest real example in this repo, and stop. No full onboarding dump.

Rules

• Every structural claim about the project cites either a graph node/edge or a file:line you actually read. Framework knowledge comes from the reference table; project facts come from the project.
• Translation ≠ equivalence. When a concept has no true counterpart (Django has no DI container; Go has no decorators), say "no equivalent — here's the idiom that fills the role" rather than forcing a false mapping.
• Match the codebase's dialect, not the framework's textbook style. If this Django repo puts logic in fat models rather than a service layer, translate to what's actually here and note the difference.
• Don't dump the whole reference table at the user — use it to answer what was asked, in the shape of their question.