Apsis — Change-Impact Reviewer

• 

  Apsis

Inspiration Reviewers approve merge requests half‑blind. "What else calls this? Is any of it untested? Does it touch a known vulnerability? Who actually knows this code?" — answering means stitching together code search, the security dashboard, CI, and tribal knowledge. GitLab Orbit finally makes all of that one queryable graph, so we turned it into a decision at the merge request.

What it does On a merge request, Apsis finds the changed definitions, then uses Orbit to compute and post a structured risk report:

💥 Blast radius — callers/dependents across services (incoming CALLS/EXTENDS, depth ≤ 3; cross‑module via IMPORTS). 🔴 Project vulnerabilities touching the changed files. 🧪 Untested impacted paths (with - [ ] action items). 🔗 Related work items and 👥 suggested reviewers (from authorship). 📊 a transparent 0–100 risk score and a proof‑beat footer (Orbit queries/latency/tokens vs the traditional way).

How we built it: A deterministic, fully unit‑tested Python engine (83 tests, 95% coverage, ruff + mypy clean) that uses all five Orbit query types (search/traversal/neighbors/path_finding/aggregation) over the REST API. It's schema‑adaptive — every node/edge name resolves through one binding layer, so it survives Orbit schema changes — and it degrades gracefully (any missing enrichment never crashes the review). It's wrapped as a Duo Agent + Skill published to the AI Catalog, and it dogfoods itself: a CI job posts an Apsis report on Apsis's own merge requests.

Why it matters: Every team that reviews MRs benefits. Apsis catches risky merges, security exposure, and test gaps automatically, and installs in one click from the AI Catalog. Because the engine is schema‑adaptive and the report meets developers inside the MR, it's trivially replicable across projects and languages Orbit indexes.

What makes it new : Most tools treat Orbit as fancy code search. Apsis exploits the half nobody else does — the cross‑domain graph linking code ↔ vulnerabilities ↔ work items ↔ users — bridging Orbit's separate code and SDLC sub‑graphs through Project/Branch and the MR. It also measures Orbit's advantage live (≈1.7× fewer queries, ≈8.3× fewer tokens on our demo) instead of asserting it.

Designed for reviewers: Zero‑config, runs where developers already are (the MR), skimmable TL;DR, actionable checkboxes, clickable work items, an explainable score breakdown, and honest disclosures (no silent truncation; "unavailable" vs "zero").

Challenges Orbit's code and SDLC data are separate sub‑graphs (no direct code→vulnerability edge), so enrichment had to bridge via Project/Branch and the MR; vulnerabilities are project‑scoped, which we state honestly rather than overclaim. We also kept the whole test suite offline with recorded fixtures so nothing depends on a live network.

Accomplishments A production‑shaped, fully tested tool that turns Orbit's graph into an actionable review — and uses itself in CI.

What we learned The verified Orbit ontology (edges CALLS/DEFINES/IMPORTS/EXTENDS, the Project/Branch bridge) and that a thin schema‑binding layer is what makes an Orbit integration durable.

What's next Auto‑create work items for untested paths, draft fix‑MRs for vulnerabilities, a group‑wide impact dashboard, and an interactive HTML blast‑radius graph.

Built With

• ai-catalog
• gitlab
• gitlab-ci
• python
• pyyaml