Every team that has tried to pay down technical debt knows the giant cleanup pull request. Four hundred files, a heroic weekend, a description that says "refactor". It sits open for two weeks while everyone finds a reason not to review it, and when it finally merges something subtle breaks and nobody can tell which of the two hundred changes did it.
Rotwise is built on the opposite instinct. Here are the rules the fix pipeline follows, and why.
Never touch main
Rotwise does not commit to your default branch. Ever. Every fix starts as a dry run you can inspect in the browser, and only becomes a branch and a pull request after a person clicks approve. There is no autonomous mode, and there will not be one in the MVP. The point of a tool like this is to give you leverage, not to take the decision away from you.
Sequence by risk, not by file
Findings are ordered before they are grouped. Security first, then correctness, then missing tests, then performance, then configuration, then maintainability. Inside each category the highest severity goes first. Low-severity smells never make it into a batch at all; they stay in the report for when you have a quiet afternoon.
The result is that your first pull request from Rotwise is the one that matters most: the leaked key, the SQL built from a string, the endpoint with no authentication. Not the renamed variable.
Keep it small enough to read over coffee
A batch holds at most eight findings and changes at most 300 lines. If a proposal would exceed that, it is split. You can override the line limit for a specific batch, but you have to say so.
Inside the pull request every finding is its own commit, so the diff reads like a story: one commit, one problem, one fix. Reviewing it is a matter of minutes, and if you disagree with a single change you can drop that commit rather than reject the whole batch.
Validate statically, never by running your code
Before you ever see a proposed fix, Rotwise checks that the patch applies cleanly and that every touched file still parses. What it does not do is run your test suite or your application inside our infrastructure. That is a security boundary, not a shortcut: your code runs in your CI, on your machines, with your secrets. We validate the shape of the change; your pipeline validates the behaviour.
Tests before behaviour
When a file has no tests, a batch that changes its behaviour will first add characterization tests that pin down what the code does today. Only then does the refactor land. It is slower by one commit and it is the difference between "the tests pass" and "the tests would have caught it".
One batch, one pull request, one revert
All of the above exists to make one promise true: if a fix turns out to be wrong, undoing it is a single revert of a single pull request. No archaeology, no partial rollbacks, no "which part of the refactor was it".
When the pull request merges, Rotwise notices, rescans the repository, and offers the next batch. Debt goes down in a steady line instead of a heroic weekend, and shipping never stops.