Concrete-First, Never Generalize in Anticipation

"Build the real thing in front of you. Let the abstraction earn its place from a second real thing — never from a guess."

The Spine You've Been Walking

One rule has been quietly load-bearing in every track of this quest, and now it gets named: concrete-first, never generalize in anticipation. You build the specific, real case in front of you. You do not build the general, flexible, future-proof version until a second concrete case forces the abstraction into existence. Anticipatory generality is a guess about the future, and guesses about the future are usually wrong and always expensive.

It Showed Up Everywhere

Where concrete-first appeared in this quest:
  Track 4  design the API for the ONE real client (the UI), not imaginary ones
  Track 5  wrap MIR as parts; don't build a framework you don't need yet
  Track 7  stay web until a forcing function appears; dev Vite until a 2nd consumer
  Track 8  ship v1's concrete scope; defer the speculative half

Four different decisions, one principle. Each time, the tempting move was to build the general version up front — a provider-neutral API, an MIR framework, a production pipeline, a feature-complete v1 — and each time the discipline was to build only the concrete thing and let generality wait for a real second case.

Specialize on Demand

The positive form is 'specialize on demand.' Don't pre-build the abstraction; build the concrete thing well, and when a second real case appears that genuinely shares structure, then extract the abstraction from two real examples instead of one imagined one. Abstractions distilled from two real cases are almost always right; abstractions guessed before the first case is even finished are almost always wrong. Bonfire is concrete-first all the way down — and that's why it shipped a real v1 while its more ambitious predecessor froze.

Code

One rule, many faces, across the quest·text

Where concrete-first appeared in this quest:
  Track 4  design the API for the ONE real client (UI), not imaginary ones
  Track 5  wrap MIR as parts; no framework you don't need yet
  Track 7  web until a forcing function; dev Vite until a 2nd consumer
  Track 8  ship v1's concrete scope; defer the speculative half

# Specialize on demand. Extract the abstraction from TWO real cases,
# never from ONE imagined one.

Exercise

Find an abstraction in your own code that has exactly one real user (one caller, one implementation, one config). Ask honestly: was it extracted from real repetition, or built in anticipation of a second case that never came? If it's anticipatory, what would inlining it back to the concrete case cost — and what flexibility were you actually paying for?

Hint

An abstraction with one user is a guess that hasn't been tested. Sometimes the guess is cheap insurance; often it's complexity with no payoff. The tell is whether a real second case ever showed up to justify it.