Code-review tooling¶

Who this is for: maintainers responding to CodeRabbit (CR) and SonarCloud (SQ) findings during a PR review cycle. This page documents the canonical query APIs and the OSS-plan rate-limit posture so a fresh contributor (or a fresh agent session) can audit findings deterministically instead of guessing.

This repo runs two automated review tools on every PR:

Both tools surface findings on PR-open and on every push. The C8 step of the post-PR checklist requires the maintainer to pull every open finding, verify against the current working tree, and either fix or document a disposition before requesting re-review.

The query commands below are the canonical way to do that pull — they do not depend on the GitHub web UI rendering finished by the time you check.

CodeRabbit — query protocol¶

CodeRabbit posts to three distinct surfaces. Pull each one separately.

1. Review state (CHANGES_REQUESTED / APPROVED / COMMENTED)¶

gh api repos/{owner}/{repo}/pulls/{N}/reviews \
  --jq '.[] | select(.user.login | contains("coderabbit")) | {id, state, submitted_at, body_preview: (.body[0:200])}'

The most recent submitted_at wins. state controls whether the PR is blocked by the request-changes workflow.

2. Inline file/line comments¶

gh api repos/{owner}/{repo}/pulls/{N}/comments \
  --jq '.[] | select(.user.login | contains("coderabbit")) | {id, path, line, body: (.body[0:400])}'

These are the actionable findings. Each comment maps to one file + one line in the PR diff.

3. Walkthrough / summary comment¶

gh api repos/{owner}/{repo}/issues/{N}/comments \
  --jq '.[] | select(.user.login | contains("coderabbit")) | {id, created_at, body: .body[0:1000]}'

The first ~49 KB block is the walkthrough. It contains the high-level summary, suggested labels, sequence diagrams, and the "estimated review effort" — useful context, but not the actionable findings list (use call #2 for that).

4. Trigger a fresh review manually¶

When auto_pause_after_reviewed_commits has paused auto-review (see config rationale), trigger a one-off review by posting @coderabbitai review (incremental) or @coderabbitai full review (from scratch) as a PR comment.

SonarCloud — query protocol¶

SonarCloud's web project is public, so its REST search API is reachable without authentication.

List all new issues introduced by a PR¶

curl -sS "https://sonarcloud.io/api/issues/search?\
componentKeys=sergienko4_israeli-bank-scrapers&\
pullRequest={N}&\
issueStatuses=OPEN,CONFIRMED&\
sinceLeakPeriod=true&\
ps=100" | \
  jq '.issues[] | {key, severity, type, component, line, message, rule}'

Get gate status for the PR¶

curl -sS "https://sonarcloud.io/api/qualitygates/project_status?\
projectKey=sergienko4_israeli-bank-scrapers&\
pullRequest={N}" | jq '.projectStatus.status'

Returns OK, ERROR, or NONE. The SonarCloud Scan CI job is GREEN iff status == "OK".

CodeRabbit config rationale¶

This repository is a public MIT-licensed fork. CodeRabbit auto-classifies it as Open Source plan — see docs.coderabbit.ai/management/plans:

PR #281 exhausted the per-hour cap when 6 incremental commits were pushed within ~90 min. CodeRabbit's default auto_pause_after_reviewed_commits of 5 was too high to throttle that burst.

The current .coderabbit.yaml is tuned for the OSS plan with the following deliberate choices:

Workflow implication: batch fixes into 1-3 commits per PR cycle, not 6+. After 3 reviewed commits CR auto-pauses; comment @coderabbitai review on the final cleanup batch to get the verdict review.

Disposition trace¶

Every CR + SQ finding gets a row in the maintainer's session ledger (hardening_todos + cr_findings SQLite tables) with verdict (real, false-positive, pre-existing) and action (fix-applied, deferred-to-phase-X, wont-fix-rationale). The PR body's ## Guideline compliance section links each cluster to the disposition for auditors.

See C:\tmp\guidelines\post-pr-checklist.md (C8 row) for the full canonical protocol.