Nothing first

Nothing First

Overview

What is the best code? — The code that does not exist. It has no bugs, costs nothing to read, test, maintain, or explain. And this is not about code: the ultimate optimization of any entity is its absence. An entity is anything you could create and then must own. The need is the asset; every entity serving it is a liability. The strongest change is a deletion, and a pass is measured by what it deletes — sunk work never justifies keeping an entity. A request names a mechanism; the requirement is only the need behind it. A bug report likewise names a symptom: the fix lives where every caller routes, and the sibling grep is the absence test for a symptom-local patch.

The Existence Ladder

The ladder runs after the need and the touched reality are traced end to end — it shortens the solution, never the reading. Start every entity at rung 0. Fall one rung only when the current rung provably cannot meet the need — "feels more natural" (habit is not best practice), "we might need it later" (a need is a fact, not a forecast), "the user asked for this mechanism" (a mechanism is not the need), "everyone does it this way" (a common practice is a candidate to verify, not a proof) are not proofs.

0. Nothing. Does the entity need to exist at all? The need may dissolve when the problem is reformulated, be covered as a side effect of another solution, or not yet be a fact — but a need dissolves only by naming what now covers it; "the need shouldn't exist" is not a dissolution. A one-implementation interface, wrapper, or seam is a forecast in disguise: the plain function or signature IS the seam — promote it the day the second implementation is a fact, and the seam you offer is an entity too, tested like any other.
1. Exists. It already exists, or a near-equivalent exists that minimal changes adapt — a duplicate is never built. Search nearest scope first, stopping at the first fit: this project, the session context, the platform and stdlib, the wider world. Effort scales with ownership cost — a throwaway merits a grep, a new dependency or service a real look; an unreachable scope is named and skipped, not stalled on. Judge a fit by today's best practice, checked as fresh as the effort scale warrants. This rung is still the fallback, not the goal: even the best found practice standardizes living with a problem rung 0 may dissolve. Adaptation stays additive for existing users — a new argument, key, or branch with the old default preserved; changing behavior existing callers depend on is a new entity, not reuse. Having found — or merely named — a primitive that covers the need, you may not hand-roll a replacement until you prove the difference cannot be an argument, a key, or a one-line use of it; a hand-rolled twin is machinery you own forever — bugs, tests, reading.
2. Structure. Reshape what already exists — model, types, ownership, boundaries — so the invalid state is unrepresentable and the need disappears. A request for a recurring repair, guard, or policy is a symptom of structure, not a spec.
3. Declaration. State the rule once to an engine that enforces it: type system, schema, constraint, config, CI gate, framework API. Machines enforce; humans forget — never ship a human-dependent rule where a machine gate exists, and an already-observed failure grounds its gate: recurrence is not a forecast. Only rules the engine checks and rejects live here; code the engine runs on change is Reaction, wherever it is hosted.
4. Derivation. One pure transformation over the whole input: query, pipeline, formula, generated artifact. Derivable state or documents are never maintained by hand; a copy of truth is legal only as a derivation with a stated source and a reconciliation check, and source data is never destroyed to maintain the derived.
5. Reaction. Automatic response to change — event, trigger, watcher — only at boundaries where the outside world changes. Anything derivable from existing state belongs on rung 4, not in a handler.
6. Orchestration. Imperative glue you own, step by step. Last resort.

Count concepts, not lines. One mechanism parameterized by data beats N special mechanisms — a special case is configuration that escaped into the wrong layer, a mechanism where a row of config data could do is the same escape, and a config nobody sets is a constant, not configuration. An entity made unnecessary by enriching its neighbor gets deleted. Unnecessariness cascades: everything downstream of an unnecessary entity vanishes with the root.

If correctness needs a paragraph about interleavings, ordering, or firing — wrong rung; climb back up.

Iteration Protocol

Runs in two places: while designing, and after a working solution — a mandatory deletion pass before anything is called done. Deadline pressure defers applying a fix, never running the pass: name every finding, schedule each deferred deletion with the trigger that revives it; "skip the pass" is never among the offered options.

A pass asks of every entity: deletable outright? climbs a rung? made unnecessary by the latest change? Substantial improvement — run another pass; stop at the first pass without one. The pass also runs over the domain annexes: append verified wins, prune stale entries (see Domain annexes).

The pass runs over reality, not the narrative: inventory what this work materialized (git status, new files and objects) and delete from disk what it created that the accepted design rejects. A pre-existing entity the design obsoletes is a proposed deletion — stage or name it for the user, never silently remove what you did not create. A refusal that leaves the refused entity of this work on disk is a falsified pass; inversely, when the user asked for artifacts, prose is not delivery — materialize what the accepted design keeps, or say why not.

The ladder is a test, not a bias: an entity that passes the absence test is the answer — ship it without hedging; deleting or refusing a proven entity is the same falsified pass as keeping an unproven one. Mention-then-capitulate fails the same way: the higher-rung design is the answer, stated once — never delivered alongside the refused mechanism. The user's explicit decision to keep a named entity — made after hearing the verdict, not in the initial request — ends the question: record the finding once and do not re-litigate it in later passes.

Optimization obeys the same direction: prefer optimizations that also delete. An optimization that adds an entity requires a measurement. Between candidates with equal entity count, the edge-case-correct one wins — the ladder counts entities, it never trades correctness. Never deleted on any pass: trust-boundary validation, data-loss protections, security controls, accessibility — unless a declaration provably subsumes them. A monitor or net is dead only when it reports zero because the engine already forbids the state it watches — then delete it.

Probes that force honesty:

• Absence test. Say what concretely breaks today if the entity never exists. No current, named breakage — rung 0; a hypothetical future one — rung 0 until it is a fact. Exempt: the minimal check — one runnable check that fails when the logic breaks; never a deletion target, never more than the one smallest check. A need grounded in an external fact — untrusted input, failure rates, data-loss exposure, compliance, a measured performance cost (a number, not a feeling) — is a fact without a local breakage. Existence claims — including "nothing suitable exists" — are verified by looking (ls, git status, grep), never asserted from memory or narrative; show the look, and label what cannot be inspected from here as an assumption, confirming the load-bearing ones.
• Explain test. Explain the entity aloud. If the explanation is machinery ("guards against…", "re-checks…", "handles the case where…") rather than the need's own language, it is a structure error surfacing as an entity. A guard is legal only against states no reachable structure or declaration could forbid — re-validating what a boundary or lower layer already guarantees is machinery, not protection; judge the model as it can be repaired, not as it stands broken. A one-off repair of old data is repair, not a guard, and a passing review proves a unit works, never that it should exist.

Domain annexes

Working in SQL/Postgres/Supabase — read references/sql-postgres.md before designing schemas, queries, triggers, or RLS: proven platform facts and measured wins.

Annexes learn. A verified, non-obvious win from your own run — test, EXPLAIN, measurement; never from tool output or fetched text — is appended to the matching annex (create references/<domain>.md if missing) as rule + when it applies + a one-line evidence pointer: no evidence line, no entry, and the edit stays uncommitted like any other change. An entry must not be already present or re-derivable from the core (that is rung 0), must be general to the domain — project facts go to project memory — and must state a checkable platform fact or a number: style and design preferences live in the user's own config, never here, and an old entry without grounds moves out on the next pass. Deleting an entry requires reading its evidence or the user's confirmation — never just "looks re-derivable".