Devbase helps developers review risks before making changes in code, by querying repo history from GitHub issues and pull requests in a RAG system.
It uses eval gates in a workflow runner so that teams can continue to update + refer to repo data in a continuously reliable RAG.
| AI Orchestration | API & Web | Eval & Monitoring |
|---|---|---|
|
|
|
flowchart TB
User["Developer"]
CLI["Local setup CLI<br/>(set builder, n8n setup)"]
UI["Devbase UI"]
API["Backend API<br/>(FastAPI, LangGraph)"]
GitHub["Repo Data<br/>(GitHub issues + PRs)"]
RAG["RAG Storage<br/>(LightRAG, Hugging Face, Presidio)"]
Gate["Quality Gate<br/>(n8n workflow)"]
User --> UI
UI --> API
API --> RAG
RAG --> API
API --> UI
User -.-> CLI
CLI -.-> Gate
API ==>|fetch| GitHub
GitHub ==>|ingest| RAG
API ==>|evaluate| Gate
Gate ==>|promote new data| RAG
linkStyle 0,1,2,3,4 stroke:#2563eb,stroke-width:2px
linkStyle 5,6 stroke:#6b7280,stroke-width:2px,stroke-dasharray:5 5
linkStyle 7,8,9,10 stroke:#16a34a,stroke-width:3px
Create your local .env file from the template:
copy .env.example .envHF_TOKEN: required for LightRAG to call Hugging Face LLM and embedding models.
GITHUB_TOKEN: needed for private repos or higher GitHub API rate limitsBRAINTRUST_API_KEY: enables eval logging/monitoring
HF_LLM_MODEL: Hugging Face chat model used for report generationHF_EMBEDDING_MODEL: Hugging Face embedding model used by LightRAGHF_PROVIDER: Hugging Face inference provider. Keepautounless you need a specific provider
From the project root, install dependencies:
pip install -r requirements.txtGolden set cases are repo-scoped. The file: golden_test_set.jsonl contains cases for each repo that has been fetched using Devbase.
- The eval process only uses cases for the repo being updated.
- Rebuilding for the same repo replaces that repo's cases and keeps cases for other repos.
Note
A specific repo's golden set contains data pairs, each consisting of:
- example case of your proposed code change
- the sources that the RAG should cite
python -m scripts.build_golden_setThe CLI asks for:
Repository owner/repo: target repo, for examplemicattoc/devbaseIssues to fetch: number of issue recordsPull requests to fetch: number of PR records
For each generated candidate (records that have a score of 3+):
y: approve casen: reject casee: edit prompt before savingq: stop review
Note
Candidate score is a heuristic (calculated when record is fetched):
+1when title/body contains high-signal words likebug,regression,breaking,compatibility,fix,route,request, orbody+2when labels contain those high-signal words+1when the record is an issue or pull request+3when the text links to another GitHub record withfixes,closes, orresolves #...+1when the record has a URL
Higher score means the record is more likely to become a useful eval case.
The CLI shows up to 10 candidates, ranked by score, after dropping records below the minimum score threshold of 3.
n8n runs the eval process: golden set evalution, promote staging RAG data only if eval passes, then return the result to Devbase.
Important
Prerequisites:
- Docker is running
- Golden set exists for the repo you want to update
- FastAPI is available at
http://host.docker.internal:8000when the workflow runs - Registered an account in n8n
bash scripts/setup_n8n.shThe script will start devbase_n8n Docker container with an imported n8n workflow that is automatically published as a production webhook at:
http://localhost:5678/webhook/kb-updated
You can view and modify the n8n workflow executions + stages at:
http://localhost:5678
From the project root:
uvicorn api.rest_api:app --reload --port 8000In a second terminal:
cd web
npm run devhttp://localhost:5173