Concrete-First, Never Generalize in Anticipation

"Build the real thing in front of you. Extract an abstraction when a second real case asks for shared structure."

The Spine You've Been Walking

One rule has quietly carried several decisions in this quest: concrete-first, never generalize in anticipation. Build the specific real case in front of you. Do not build a general, flexible, future-proof version until a second concrete case shows actual common structure. Anticipatory generality is a guess about the future, and a wrong guess leaves complexity behind.

The Same Shape Appears in Several Decisions

Where concrete-first appears in this quest:
  Track 4  prove the API contract with an engine + first-UI vertical slice
  Track 5  keep MIR implementations behind a product-owned contract
  Track 7  validate the web boundary required by a real playback problem
  Track 8  finish v1's concrete scope; defer speculative features

The decisions differ, but the discipline is consistent. A universal client API, a chosen MIR framework, an unneeded runtime abstraction, or a feature-complete v1 can all sound prudent in advance. Concrete-first asks for evidence from a real workflow before paying for that generality.

Abstract on Demand

The positive form is 'abstract on demand.' Build the concrete thing well. When a second real case genuinely shares structure, extract the common part from the two cases. The operation is abstraction, not specialization. An abstraction extracted from real examples can still be wrong, so test it against a third case and the actual cost of change. Concrete-first is not a ban on abstraction; it is a demand for evidence.

Code

One rule, many faces, across the quest·text

Where concrete-first appears in this quest:
  Track 4  engine + first UI prove one API contract
  Track 5  MIR implementations stay behind a product-owned contract
  Track 7  validate the web boundary required by a real playback problem
  Track 8  finish v1's concrete scope; defer speculative features

# Abstract on demand.
# Extract common structure from a second real case; test it with a third.

Exercise

Find an abstraction with one real consumer. Was it extracted from repetition, or built for a second case that never arrived? If a second case exists, list the common structure and differences, then test whether today's abstraction would survive a third case.

Hint

One consumer may mean an untested guess, but it is not an automatic order to inline. Include removal cost, change frequency, and the testing value of the boundary in the decision.