Karajan family
Every merge asks the same question. This answers it: what else just became risky — and shows you why.
Shared multi-repo RAG always fresh · cross-repo impact ranked with evidence · stale documentation flagged · local embedders, your code never leaves your runner
Paste it into your AI agent (Claude Code, Codex, Cursor). It checks your machine, asks YOU what only you can decide — which repos to watch, how sensitive that code is, where the corpus lives, where alerts land — wires your own deployment repo, and stops to wait for you whenever a step needs your permission. It never handles your secrets: it tells you which ones to create and waits.
Prefer to drive? npm i -g karajan-watch and follow the configuration reference. Nothing about your organisation lives here — it all stays in your deployment repo.
Engine: kaRAGan · Node ≥ 20 · AGPL-3.0
Three things, on every merge
01
Every merge reindexes only what changed into a corpus that spans all your repos — code and docs in separate indexes, each chunk stamped with its sensitivity level.
Embedders run locally on your runner. An index that cannot be written is a red job, never a half-built corpus. How ingestion works →
02
Three independent signals: retrieval of the merged diff against the other repos, git co-changes mined from history, and an LLM verdict routed by your sensitivity policy.
Out comes a risk ranking where every entry carries its evidence — the chunk that matched, the line, the co-change count. The pipeline →
03
The same skeleton pointed at your documentation corpus: which sections mention what you changed, linked file:line, with an optional LLM pass to cut the noise.
Because the paragraph that lies is worse than the one that is missing. Documentation drift →
One merge, start to finish
Signals, not certainties — and calibrated against your own past incidents. That green is the only green on this page.
Vector similarity is not causal analysis. So there is no "87% chance of breaking" anywhere in this product: you get a ranking, and next to every entry, the evidence that put it there. You decide.
And the ranking is measurable: feed it a golden set of your own past incidents and karajan-watch eval reports precision and recall, failing the job when the thresholds you declared are not met. Calibration →
karajan-watch ships the generic machinery. The list of repos, the sensitivity levels, the thresholds and where the alerts land live in a private deployment repo of yours — which just calls the reusable workflows.
your-deployment-repo/.github/workflows/on-merge.yml
jobs:
impact:
uses: manufosela/karajan-watch/.github/workflows/impact.yml@main
with:
org: your-org
repo: backend-api
base-sha: ${{ github.event.before }}
head-sha: ${{ github.sha }}
pr-number: '412'
secrets:
REPOS_TOKEN: ${{ secrets.REPOS_TOKEN }}
PG_URL: ${{ secrets.PG_URL_CODE }}
# or drive it yourself, anywhere:
# karajan-watch ingest --workspace .kjw-workspace --corpus code
# karajan-watch impact --workspace .kjw-workspace --repo backend-api --diff merge.diff
# karajan-watch drift --workspace .kjw-workspace --repo backend-api --diff merge.diffinternal at the very least. Local embedders on ingestion, LLM judgement only through adapters your policy allows for that level, PII redacted on every output. Declare your policy →