Production docs for codebase intelligence.

The core loop is intentionally short: install the CLI, initialize a repository, index it, then ask questions. Indexing creates the graph and vector data used by every analysis command.

pip install repo-intelligence==0.1.0

cd path\to\your\project
repo init --project-name "My Awesome Project"
repo index -v

repo search "authentication flow"
repo trace UserService --depth 8
repo impact UserService
repo explain "how login works" --diagram --tree --deps
repo architecture
repo onboard --output ONBOARDING.md

# Contributor setup
git clone https://github.com/pratiksingh1702/RIP.git
cd RIP
uv sync
docker compose up -d
uv run repo --help

Runtime-aware commands accept `--mode auto|server|local`. Local mode is for offline single-developer analysis. Server mode is required for REST, Flutter, Gateway, WebSockets, remote Git indexing, shared indexes, and concurrent users.

repo doctor . --mode local
repo index . --mode local
repo explain PaymentService --mode local --no-llm --tree --deps

docker compose up -d
uv run repo serve --mode server --host 0.0.0.0 --port 8000

Configuration priority is command-line options first, environment variables second, and `.repo-intel/config.toml` third. Local mode works with no server config; server mode needs service URLs and credentials.

[graph]
neo4j_uri = "bolt://localhost:7687"
neo4j_user = "neo4j"
neo4j_password = "your-password"

[search]
qdrant_host = "localhost"
qdrant_port = 6333
embedding_model = "BAAI/bge-small-en-v1.5"

[storage]
postgres_url = "postgresql+asyncpg://user:pass@localhost:5433/db"
redis_url = "redis://localhost:6379"

[llm]
primary_provider = "ollama"
primary_model = "qwen2.5-coder:7b"
ollama_host = "http://localhost:11434"

repo config
repo config --get llm.primary_provider
repo config --set llm.primary_provider=openai
repo explain "how auth works" --no-llm --tree --deps

Every `repo` command accepts `-v` / `--verbose`. Verbose mode prints detailed runtime logs and writes `.repo-intel/logs/<command>-YYYYMMDD-HHMMSS.log` when a target repository is available.

Projects isolate graph and vector results. API keys protect server access and can be used by Flutter, REST clients, and integrations.

repo projects
repo use 3f2f-project-id
repo use 3f2f-project-id --repo-path C:\path\to\project
repo search "something" --project 3f2f-project-id

repo api-keys list
repo api-keys create "Flutter App" --description "For mobile app" --expires-in 365
repo api-keys revoke 2

The Context Gateway has its own `gateway` CLI. It starts the Gateway HTTP server, reports source health, manages source toggles, and prints MCP configuration for agents.

cd gateway
uv run gateway start
uv run gateway status
uv run gateway sources list
uv run gateway sources enable github
uv run gateway sources disable jira
uv run gateway mcp config
uv run gateway mcp-server

RIP server routes are protected with bearer tokens. Create API keys from the CLI or API, then pass them in the `Authorization` header.

Authorization: Bearer rip_xxxxxxxxxxxxxxxxxxxxx

The RIP API mirrors the core CLI surfaces for apps and integrations. Responses are wrapped in the server envelope where applicable.

Project endpoints expose indexed repositories and metadata to server-mode clients such as Flutter, dashboards, and integrations.

curl -H "Authorization: Bearer $RIP_API_KEY" http://127.0.0.1:8000/projects/

curl -X POST http://127.0.0.1:8000/api-keys \
  -H "Authorization: Bearer $RIP_ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"Flutter App","description":"Mobile access","expires_in":365}'

{
  "task": "Add audit logging to login",
  "token_budget": 6000,
  "sources": ["rip", "github"]
}

Every indexed repository has a project identity. Graph nodes and vector payloads carry project IDs so search, trace, impact, explain, and API clients can stay scoped to the intended codebase.

The Context Gateway is server-mode only. It classifies the agent task, plans source retrieval, executes sources in parallel, ranks and compresses results, checks permissions, manages sessions, and returns a context package.

cd gateway
uv pip install -e .
cp .env.example .env
uv run alembic upgrade head
uv run gateway start
uv run gateway mcp config

docker compose up -d
.\.venv\Scripts\repo.exe serve --mode server
.\gateway\.venv\Scripts\gateway.exe start

curl http://127.0.0.1:8001/health
gateway status

The VS Code extension is the editor-first interface. It exposes RIP Chat, context menu actions, architecture visualization, metrics, and index status monitoring.

Index this project
Explain how authentication works
Show architecture diagram
Trace UserService

The Flutter app connects to a server-mode RIP backend. Use `repo serve --host 0.0.0.0` so the phone can reach the server over the local network, then provide the API key in the app setup flow.

The app mirrors server-backed workflows. Project surfaces use project metadata, and remote Git indexing can be triggered with the same `subdir` semantics as the CLI.

/index https://github.com/pratiksingh1702/flutter_music_app.git --folder flutter_music_app_lib --project-name flutter_music_app_lib --subdir lib --branch main
@ project-list

RIP supports MCP so coding agents can ask for context, search, trace, impact, explain, and validation without guessing from raw files alone.

RIP MCP mirrors the documented CLI surface, including init, index, trace, impact, explain, search, projects, use, dead-code, onboard, architecture, metrics, serve, status, delete, and config tools.

{
  "mcpServers": {
    "context-gateway": {
      "command": "gateway",
      "args": ["mcp-server"],
      "env": {
        "GATEWAY_RIP_MCP_CWD": "."
      }
    }
  }
}