RedlineMR Review Bot

Redline reads a range of commits in a git repository on your own machine and writes the kind of review a teammate would leave on a merge request. It flags secrets, risky code, debug leftovers, oversized changes, missing tests, and dependency changes, then gives a verdict. It never touches a remote service and cannot push, comment, or change the repository.

The optional Claude pass is tested only with fake fetch functions. It has never run against the live API. Thresholds are fixed in code, and there is no per-repo config yet. It reviews what you point it at; it does not watch a repo or run on its own.

On the list, this project was a bot that comments on GitLab merge requests. I chose no GitLab. So I kept the useful part, a second pair of eyes on a diff before I share it, and built it to review local repositories only, with read-only git commands.

I set the hard rules: no remote services, read-only git only, execFile with an argument array, timeouts and size caps, and a repo path that must be an existing directory. Claude Code wrote the diff parser, seven deterministic reviewers, the prompt fencing, and a rules table for the verdict, then built 423 assertions around them before any UI existed. It hand-wrote a fixture diff for a fictional pantry app with planted issues. The UI came in small modules, checked with headless Chrome DOM dumps and screenshots.

The demo includes a real read-only review of the #11 QR Studio folder in this repo. Since the repo had a single commit, HEAD~1..HEAD failed at first; now a ref with no parent gets compared against the empty tree.

• A read-only promise needs more than an allowlist of subcommands. git diff --output writes a file and --ext-diff runs a program, so the checker refuses those flags too, and the environment clears GIT_EXTERNAL_DIFF.
• Treat the model like an untrusted contributor. Each hunk goes out fenced as data between content-derived markers, the reply must be strict JSON, and any finding whose line is not a new line of that hunk gets thrown out. The server checks again before saving.
• Regex reviewers live or die on look-alikes. re.exec(text) is not a shell call, innerHTML = "" is not XSS, and "Select a file from the list" is not SQL. Every rule has a test for its safe twin.
• Outputs leak too. Snippets, the stored diff, the Markdown, and the Claude prompt all go through one redaction step.
• The score surprised me. 25 low findings, mostly em dashes, plus two large files pushed a docs-heavy folder to "Request changes". I would weight style findings lower next time.

It reviews its own house rule: the em dash reviewer enforces the same no-dash rule the whole repo follows, and reports spell dashes out as "[em dash]". It hit the same Write bug as #87 that day, a dash escape turning into the literal character, and got the same fix plus a test that scans every shipped file. Every file was written under about 4 KB, the rule from the September 20 stall.

I would add a per-repo config for thresholds and ignored paths, and a "since last review" range so the history shows which findings got fixed.