Use cases / Platform teams with many kinds of repository
Rules that fit what each repository is
A public API, a CLI, a library and a prototype should not be read with the same rulebook.
The problem
One rulebook for every repository is wrong for most of them: CORS warnings on a command-line tool, test rules on a spike, and nothing extra on the one service that faces the internet. Reviewers learn to ignore the lot.
What visualdiff does
- Each repository is read through a nature: public-facing service, internal service, library, browser or mobile app, infrastructure, data pipeline, tool or prototype. The review suggests one from what the code shows, with the evidence.
- A nature steps rules up or down and sets the gates that follow from it. A person then tunes rule families or single rules by their own judgement, and adds review rules in plain words by path.
- The profile applies to every branch and pull request of that repository, and the same two keys work in a committed policy file so CI reads it the same way.
A secret is never switched off by any of this. A prototype’s maintainability rules are.
Related
- Reviewing pull requests written by agentsAgents open pull requests faster than anyone can read them. Read the 10% that decides whether it is safe.
- Large refactors that hide a behaviour changeA refactor is supposed to change nothing. Find the one line that does.
- Stopping hallucinated dependenciesSlopsquatting: attackers register the package names models invent. Catch them at review.
- Seeing which running systems a change reachesThe diff says rds.tf. The map says orders-db, the API in front of it, and the queue behind it.