Adoption · why this exists

Your codebase, before and after.

One config file and three git hooks land in your repo. Nothing else moves — your source tree is untouched. What changes is not your code, it's what you can prove about it. Below: whether it covers your stack, exactly what appears on day one, and the real numbers this site started and ended at.

01 · Does it cover my stack?

Your project runs the laws that apply to it — and it tells you the number.

The registry holds 169 laws. 62 are universal — git hygiene, docs, deployment, security posture — and apply to every project. The rest are scoped, so the count you actually run depends on what you build.

Angular · React · Vue · Ionic
132laws run
universal 62frontend 55typescript 15
Python
99laws run
universal 62python 37
Node · library · generic TypeScript
77laws run
universal 62typescript 15

No project ever runs all 169 — and we won't pretend otherwise. A Python repo has no Angular components to check; a Node library has no bundle to budget. Rule of Code detects your project type, runs the laws that apply, and prints how many actually executed. That number is the one it gates on — not the marketing total.

Browse the registerEvery law, filterable by your stackSee exactly which laws would run on your project — and what each one says it can't detect.Open the 169 laws →

02 · Day one

What appears in your repository.

No framework, no service, no vendor lock. One config file and three git hooks. Your source tree is untouched — the tool reads it, it doesn't rewrite it.

before
your-project/ src/ tests/ package.json README.md … your code, exactly as it is
after — npx ruleofcode init
your-project/ src/ ← untouched tests/ ← untouched package.json README.md ruleofcode.config.json ← your constitution .husky/ pre-commit ← blocks the commit pre-push ← blocks the push commit-msg

It doesn't restructure your code.
It restructures your feedback loop.

03 · The metamorphosis

What actually happens over the following weeks.

Day one you get a number, and it is usually ugly. Then you burn it down — honestly, never by muting a law. This is the real curve from this website's own repository, the one serving you this page.

103
laws passing today
16
visible debt — published
119
laws actually run · floor 117
96
score, out of 100

Generated at deploy from a real audit · tool v7.23.0 · a failing audit fails the build → see it live on /dogfood

A trading backend, real money

Their old config was quietly hiding 42 laws. Running the honest scope surfaced four real defects — including an outage that had read as “an expired token”, with nothing logging it. Debt went 22 → 8. Today: 93 laws, 0 failed, 0 waivers.

consumer report · July 2026 · their numbers, not ours

The tool itself

Our own repo once ran 5 of 169 laws while the banner printed “169 LAWS!”. Sixteen dead config keys had shrunk the set. The audit still reported the real number and exited non-zero — the banner lied, the verdict didn't. That's why the liveness floor exists.

our bug · on the wall of findings

04 · The end state

Every applicable law passing, at error severity. Here is what that means — for your stack.

This is the destination, in black and white. Not adjectives — the properties your repository provably has once nothing is left unmet and every law is blocking, not advisory. Pick your stack; the counts are the real law set that runs on it.

Angular · React · Vue · Ionic the repository as it exists when nothing is left unmet
132 laws · all error · all passing
your-project/ .github/workflows/ci.yml ← Automation First Principle · PR Workflow Standards .husky/ ← Git Hooks Standards pre-commit · pre-push · commit-msg ← Git Hook Compliance docs/adr/ ← Strategic Document Updates src/app/ feature/ feature.ts ← OnPush + standalone enforced feature.spec.ts ← Unit Test Quality · Coverage Standard README.md ← Code Documentation Standards store/ *.state.ts · *.reducer.ts ← NgRx Feature Store Structure *.effects.ts · *.selectors.ts ← Effects Error Handling · Store Pattern CONSTITUTION.md ← Constitutional Supremacy Doctrine CONTRIBUTING.md ← Git History Integrity · Commit Size · Review Quality CODEOWNERS ← PR Workflow Standards · Code Review Quality CHANGELOG.md ← Release Tag Standards · Documentation Standards SECURITY.md ← Security Vulnerability Response LICENSE ← Documentation Standards README.md ← Documentation Standards eslint.config.mjs ← Investment-Grade Quality (SACRED) tsconfig.json ← TypeScript Strict Mode (SACRED) — strict, noImplicitAny ruleofcode.config.json ← your constitution, with the liveness floor
Every line above is a checked property, not a promise. Each of these laws also declares in writing what it cannot detect — a passing audit is a verified floor, and it says so itself. That is the difference between this and a badge.

And these are not files.

Structural properties the same law set enforces — the part that changes how the codebase is shaped, not what it contains.

Framework31Every component OnPush and standalone; effects handle their own errors; the store is split state / reducer / effects / selectors instead of one file; routes lazy where they should be.
Code quality20Zero any, zero non-null assertions, zero double casts in the tree. Complexity bounded per function, duplication under threshold, no magic numbers left in source.
Version control15Conventional commit subjects, governed branch names, bounded commit size, no conflict marker ever reaches a branch, hooks armed on every clone.
Security14No secret anywhere in the tree, XSS boundaries enforced, dependency scanning wired, auth paths covered by tests rather than assumed.
Performance14Bundle budgets enforced at build time, Core Web Vitals tracked, caching strategy declared, monitoring that actually feeds an alert.
Testing13Coverage held to the standard and the tests themselves checked — no empty describes, no assertion-free specs, managed test data, API and security paths covered.
Documentation10A README beside every module, public API documented, TODOs tracked with an owner rather than abandoned in a comment.
Sacred laws7Strict TypeScript, zero tolerated warnings — the seven that cannot be waived without a written argument.
Deployment7Pre-deployment checks that actually run, environment parity verified, health endpoints live, an incident path written before the incident.
Accessibility5a11y linting enforced, ARIA state correct on disclosure controls, explicit button types, every form control labelled.
✅ CONSTITUTIONAL COMPLIANCE: PASSED exit 0

And then it prints a unicorn.

There is no --unicorn flag and no --force. It appears on one condition — every applicable law passed — and the fast path can never reach it: a subset cannot pass what it did not run.

Most days this tool tells you no. This is the other side of it, and it is the only part you cannot fake.

05 · The difference, day to day

The same team, the same code — two different loops.

Nothing here requires a bigger team or a rewrite. It's the same work, with the feedback arriving at a point where it's still cheap to act on.

Without
With Rule of Code
“Is this codebase healthy?”
An opinion, defended in a meeting. It depends who you ask and how tired they are.
A number anyone can reproduce in one command — and a list of exactly what is unmet.
A rule the team agreed on
Lives in a wiki page nobody reopens. Enforced when a reviewer happens to remember it.
Executable. Enforced on every commit, for everyone, including the people who wrote it.
A regression slips in
Found in review if you're lucky, in production if you're not. The fix costs a release.
The push is refused before it leaves the machine. The fix costs a minute.
A new contributor arrives
Learns the conventions by being corrected in pull requests, one comment at a time.
The rules run locally on their first commit — the tool does the correcting, reviews stay about design.
Technical debt
Invisible. It accumulates at the speed of “we’ll fix it after merge”.
Counted and named. Warnings are debt you can see; the number only moves when work happens.
The green checkmark
Means the checks that ran, passed. Nobody knows how many ran, or whether that shrank last month.
Means the checks ran and the count was verified against a floor — below it, the audit refuses to report at all.

06 · What it will not do

The list that makes the rest believable.

A tool that claims everything is the artifact this product exists to kill. So, plainly:

It will not write your code

No refactors, no generated tests, no autofix that rewrites your source. It reads, it reports, it blocks. The work stays yours.

It will not fix a bad architecture

It can tell you complexity is climbing and boundaries are leaking. Deciding what the system should have been is still an engineering judgement.

It will not know if your product is right

Every law here is about how the code is built, never about whether the feature should exist. A perfectly compliant repo can still ship the wrong thing.

It will not pretend to see everything

Each law declares in writing what it cannot detect. A passing audit is a verified floor, never a guarantee — and it says so.

Read before you trustOur own audit, published in full16 unmet laws, 13 argued exemptions, and the blind spots we've reported to ourselves — all on one page.See /dogfood →

Five minutes to install. The number is yours after that.

Free, MIT, local. Run it once and you'll know what your repository would score before anyone else asks — including the auditor you haven't met yet.