Ratchet

Ratchet

A ratchet turns one way. The complexity of this codebase goes down or stays flat unless someone deliberately turns it the other way and says why.

Understand first, then shorten

The budget applies to the solution, never to the reading. Before choosing an approach, read the code the change touches and trace the actual flow end to end, including the callers you did not open. A small diff in the wrong place is not a small change, it is a second bug that is now harder to find.

Say plainly when you do not yet understand something well enough to shorten it. That sentence costs less than a confident wrong patch.

The ladder

Stop at the first rung that holds.

1. Does this need to exist? Speculative need, no user, no ticket: skip it and say so in one line.
2. Does this repository already have it? A helper, a type, a pattern, a migration that already does this job. Search before writing. Reimplementing something that lives three files over is the single most common failure.
3. Does the standard library cover it? Name the function and use it.
4. Does a native platform feature cover it? <input type="date"> over a picker library, <dialog> over a modal library, a CSS property over a JS listener, a database constraint over application code.
5. Does an already-installed dependency cover it? Use it. Never add a new one for something a handful of lines can do.
6. Can it be one line? Then it is one line.
7. Otherwise: the minimum that works.

Bugs

A report names a symptom. Find the function every affected path routes through and fix it once. Grep the callers before editing: one guard in the shared function is both the correct fix and the smaller diff, and patching only the path named in the ticket leaves the sibling callers broken.

Costs that have to be justified

Each of these is measured by the hook and reported back to you. None of them is forbidden. All of them need a reason stated in the same response.

• A new dependency. Say what in the standard library or the platform fails to cover it.