Map the Blast Radius Before the Review: A Per-Symbol Ledger for Small OSS Patches

A four-line patch, two approvals, and a retry that never fires

A small project ships a four-line change to an error-handling branch late on a Friday afternoon. Two reviewers read the diff, both approve it, and the patch merges with a green CI run. Three weeks later a downstream consumer reports a retry loop that never fires, and the root cause sits in a caller nobody re-read. That story is a composite illustration rather than a logged incident, but it captures a real tension in small-maintainer projects: review attention is scarce and the diff is the only surface anyone inspects.

Whole-repository review prompts do not fix this, because they spend effort rescanning untouched code. Pure hunk-level prompts fail in the opposite direction, because a diff without its consumers hides every caller that depends on the changed behavior. What a maintainer actually needs is a compact, per-symbol artifact that lists the blast radius of each change and the commands that could falsify the author's claims.

Why per-symbol packets beat whole-repo prompts

• A repository-scale prompt forces a model to restate imports, configs, and unrelated modules instead of testing the change under review.
• A hunk-only prompt omits call sites, so a signature change looks harmless until a downstream branch dereferences a now-nullable value.
• Neither format yields something executable, so approvals end up resting on prose instead of on observable checks with exit codes.
• Small maintainer teams rarely have a second human reviewer available, which is exactly where a cheap breadth pass earns its place.

The workflow below is a proposal, and the scripts are unexecuted sketches meant to be adapted. It produces one ledger row per changed symbol, each row carrying its call sites, its referencing tests, and a small packet that a free model can review in isolation. Substitute your own build commands wherever make test appears.

Step 1 — Freeze a reproduction receipt first

No review should start before the base commit and the current test state are recorded in a single file. The receipt removes the most common argument in OSS threads, which is whether the failure even exists on the author's machine. Keep the log hash so a later rerun can prove the environment changed rather than the code.

set -euo pipefail
mkdir -p .review
BASE=$(git merge-base origin/main HEAD)
{
  echo "base=$BASE"
  git rev-parse HEAD
  python3 --version
  git --version
} > .review/receipt.txt
make test > .review/baseline.log 2>&1 || echo "exit=$?" >> .review/baseline.log
sha256sum .review/baseline.log >> .review/receipt.txt

Step 2 — Derive the blast radius from hunk headers

Git already knows which function each hunk belongs to, and -U0 keeps the output small enough to parse. The hunk header after the second @@ carries the enclosing function or class context, which is precisely the symbol under review. Inspect it manually before automating anything.

git diff -U0 "$BASE"...HEAD | grep -E '^@@' | head -n 40

Each matching line becomes one ledger row, and each row gets its own call-site search. The search is deliberately textual and dumb, because a call-graph tool that fails to resolve dynamic dispatch produces false confidence. Filter vendored directories, then confirm every surviving hit by reading it.

Step 3 — Emit one ledger row per changed symbol

The script below reads the hunk headers and writes a Markdown table with candidate call sites. It is intentionally short enough to audit in a review, since a 400-line helper script becomes its own maintenance burden.

# ledger.py — proposal, not executed in this article
import re, subprocess

def sh(*args):
    return subprocess.run(args, capture_output=True, text=True, check=True).stdout

def symbols(base):
    diff = sh('git', 'diff', '-U0', f'{base}...HEAD')
    rows = []
    for line in diff.splitlines():
        m = re.match(r'^@@ .* @@\s*(.+)$', line)
        if not m:
            continue
        ctx = m.group(1).strip()
        name = re.split(r'[(\s:]', ctx)[0]
        if re.fullmatch(r'[A-Za-z_][A-Za-z0-9_]*', name or ''):
            rows.append(name)
    return sorted(set(rows))

def call_sites(name):
    hits = sh('git', 'grep', '-n', '--', name).splitlines()
    return [h for h in hits if '/vendor/' not in h]

base = sh('git', 'merge-base', 'origin/main', 'HEAD').strip()
for name in symbols(base):
    hits = call_sites(name)
    print(f'| `{name}` | {len(hits)} | ' + '<br>'.join(h.split(':')[0] for h in hits[:6]) + ' |')

Step 4 — Use a free-model breadth pass on each packet

A packet per symbol stays small, so a free model can read several of them without being asked to hold the whole repository in context. MonkeyCode is relevant at this step for two operator-supplied reasons: it offers free model access and a free server option, which lowers the cost of running breadth passes over many small packets. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Specific quotas, hardware, and duration are not verified here, so confirm the current terms on the project's own pages before depending on them.

The prompt below asks for claims, checks, and unknowns rather than a verdict, because a model's approval carries no accountability. Keep the packet to the hunk, the symbol name, the call sites, and the tests that mention the symbol.

You are reviewing one changed function, not a repository.
Inputs: symbol name, unified diff hunk, direct call sites, tests referencing the symbol.
Output exactly three sections:
1. CLAIMS — behaviors this change could alter, one per line.
2. CHECKS — one shell command per claim that would prove it false.
3. UNKNOWNS — invariants you cannot verify from this packet.
Do not restate the diff. Do not praise. Do not approve.

Step 5 — Falsify every claim before anyone approves

The value of the packet is that each CLAIMS line maps to a command a maintainer can actually run, so the review ends with evidence instead of adjectives. Record verdicts in the PR description, and mark anything unverifiable as an explicit unknown rather than a silent pass. The rows below are illustrative placeholders, not output from a real run.

Claim from packet	Check command	Verdict	Action
Retry branch is still reachable	go test ./client -run TestRetry -count=1	pass	keep
Caller assumes a non-nil return	git grep -n 'fetchConfig(' -- '*.go'	3 hits, 2 unchecked	add guard or note in PR
New timeout changes default behavior	git grep -n 'defaultTimeout'	4 configs, none tested	flag as unknown

The falsification loop is short enough to run by hand, and that is a feature rather than a limitation. Automating it too early hides disagreements about what a check actually proves.

while IFS= read -r cmd; do
  printf '>>> %s\n' "$cmd"
  bash -c "$cmd" && echo 'PASS' || echo 'FAIL'
done < .review/checks.txt

When a free-model breadth pass is worth the tokens

Change shape	Breadth pass	Human depth pass	Reason
Mechanical rename across many files	yes	spot-check	errors are local and greppable
Auth branch or crypto constant	no as sole reviewer	required	accountability cannot be delegated
Error message or log text	yes	skip	low blast radius
Concurrency primitive or lock ordering	yes for hypotheses	required	runtime invariants are invisible in diffs
Docs, comments, license headers	skip	lint instead	mechanical tooling is cheaper

The table is a starting point rather than a policy, and each row should be re-argued when the repository's test suite changes. Teams that cannot name a command for a claim should treat that claim as an unknown.

Limitations and who should skip this

• A model cannot run the suite, so any claim about runtime behavior stays a hypothesis until a command settles it.
• Textual call-site search misses reflection, generated code, and dynamic dispatch, which inflates confidence in languages that rely on them.
• Free-tier availability and capacity can change without notice, so a workflow that hard-depends on it needs a fallback path.
• Proprietary or license-restricted code should not be pasted into any hosted endpoint until data handling is confirmed by the operator.
• Security-critical patches still need an accountable human reviewer, and model output should never be recorded as an approval.

The ledger adds overhead on trivial patches, and a two-line documentation fix does not justify it. It pays off when a change touches shared symbols, when reviewers are scarce, or when a previous patch merged cleanly and still broke a consumer.

If the per-symbol ledger fits an existing maintainer workflow, check the project's current documentation for the free access and server terms before adopting it, and keep the fallback path written down.

What to keep after the patch merges

Archive the receipt, the ledger table, and the falsification log next to the pull request link, because the next bug report will reference one of them. A three-file record answers the questions that usually reopen a dead thread: what was tested, on which base commit, and which claim was never verified. That archive is cheap to keep and far more useful than a review thread nobody can reconstruct.