My review-fix workflow found 15 material issues. CodeRabbit found none.

Fifteen material findings to zero valid findings.

In July 2026, I ran my repository-aware review-fix workflow over two real changes in my engineering standards repository. I cloned the original and repaired heads into four pull requests and asked CodeRabbit Pro, on its Assertive profile, for full reviews.

review-fix found fifteen distinct problems across its review, repair, and verification stages. Fourteen changed the product, its tests, or the instructions people follow when adopting it. The fifteenth was a real credential risk that I accepted after a live probe showed there was no lower-privilege route. CodeRabbit left one comment. That comment was a false positive.

The findings changed whether the work was safe to ship.

The complete reports list every finding and its disposition: the nine findings in the policy-checking change and the six findings in the GitHub permissions change. Every finding remained valid on re-audit. Fourteen were fixed. I accepted the remaining security risk and recorded why.

• A quality check that gave the wrong answer. It skipped files that should have been checked and sometimes mistook ordinary text for a violation. A broken change could pass. A clean change could fail.
• Results that went stale or reran every time. The check could reuse an old result after its inputs changed. The first repair swung too far and forced a rerun every time. The final repair made the result change only when its real inputs changed.
• Adoption instructions that led to a dead end.The change required a release that nobody could install yet. Its instructions also described behavior that had been removed. Both had to be corrected before another repository could adopt the change.
• Error messages that sent people in the wrong direction.The permissions checker called an access problem a network outage. It also blamed permissions for failures with other causes. Someone following those messages would troubleshoot the wrong system.
• A credential that could read more than intended.The narrower permission failed a test against a private repository. I accepted the extra read access and documented the controls around the credential.

CodeRabbit reported no actionable comments on either original snapshot, including the permissions change and the policy checker. It also found nothing on the fully repaired policy checker. Those original snapshots contained the first-pass defects. CodeRabbit had a clean chance to catch them and missed all of them.

The whole package already followed one consistent design.

On the repaired permissions change, CodeRabbit objected to a plain error class, throw, async/await, and try/catch. It cited a general repository rule and asked two files to adopt Effect, a different way to manage async work and errors. The comment is still public.

The package already used plain TypeScript async and error handling throughout. It is a small bootstrap tool that runs before the rest of a project is installed. Adding Effect to the two changed files would have given one package two competing ways to handle the same errors and added another dependency to a tool designed to start with very few. That design was later written into its local instructions. The same pattern already appeared throughout the code CodeRabbit reviewed.

CodeRabbit applied the broad rule without checking how the package was built. review-fix kept the package consistent. Following CodeRabbit's comment would have left two files handling errors differently from the rest.

It is a bounded workflow with a hard stop and a human handoff.

The first review checks the change against its intended behavior and the repository's own decisions. The repair stages then treat every fix as new code. That second look matters because a sensible repair can solve one problem and create another.

Eight of the fifteen findings appeared while checking repairs. One fix made the quality check reject clean code. Another made the check rerun on every build. A third corrected one error message while leaving related messages wrong. Each problem was easier to see in the small set of new repairs than in the full change.

CodeRabbit reviewed the original and final snapshots. The originals exposed every initial defect; CodeRabbit missed them. The temporary repair defects were gone by the final heads. The comparison measures that workflow advantage directly: review-fix inspects its own repairs.

The hard stop came from a 46-hour review-loop experiment. The predecessor turned a 179-line change into 37,451 added lines and changed live repository settings before I stopped it. review-fix replaced that open-ended behavior with the forward path in the diagram. On these two changes, the workflow found fifteen material problems. The snapshot reviewer found none.