Knowledge graph of the repo under review

The reviewed repo gets a graphify graph, collapsed to a file-level index the server reads per request:

ops/refresh-graph.sh owner/name   # clones if needed, then builds the AST graph + file-level index

GET /preflight reports availability. Without an index every feature below degrades to "not available" — and the rules stay silent rather than implying safety.

Per file, all free at review time (no AI, no tokens):

community	which subsystem, by name — derived from the dominant directory when unlabelled.
dependents / dependsOn	who needs this file and what it needs, each marked in-PR or not.
tests	specs that cover it, same-name first, flagging how many the PR didn't touch.
flows	named multi-file flows from graphify hyperedges.
notes	rationale the graph pulled out of comments and docs — the WHY grep can't produce.
hubRank	rank among the repo's most depended-on files.

Two deterministic rules ride on it:

• blast-radius — changed files whose callers aren't in the PR. Those files can break without appearing in the diff. SKIP-bucket files are excluded (generated code has thousands of dependents).
• hub-file-changed (high) — the PR touches something the whole repo leans on, e.g. i18n/index.ts with 844 dependents.

The same context feeds the judge and explain prompts, so the model is told the dependents and rationale instead of spending turns grepping for them.