refinement vs redesign
refinement preserves; redesign replaces.
what it teaches
- Refinement keeps the incumbent identity, behavior, copy, and everything outside scope. ask before replacing factual copy or adding claims.
- Redesign keeps product truth, content, function, and constraints — treats the old look as evidence and anti-reference. choose a replacement world; replace the design document. never split the difference into polish on the discarded look — the half-state inherits neither world's coherence.
- visual authority is evidence, not a filename. a missing DESIGN.md does not make a project greenfield: if a coherent identity lives in the code, document it rather than inventing a replacement. conversely, an existing document doesn't override what the code says.
- local additions inherit their surface. a section, component, or state inside an established surface is never an identity exercise.
why
prevents silent scope creep of taste: a "polish" request drifting into world-replacement, or a redesign that hedged and shipped a compromised in-between. naming the two operations — and forbidding the blend — makes scope explicit and reversible only by saying so.
when to use
every design request on existing code: classify refinement or redesign first, then hold the line for the whole engagement.
good and bad
bad
request: polish the workflow dashboardchange: replace its typography, palette, layout, and navigation
the stated refinement silently becomes an unapproved new visual world. the requester loses the surface they asked to keep, review compares against nothing agreed, and later "polish" requests inherit the precedent that scope is negotiable. the blend inherits neither old nor new coherence, so the cost repeats at the next redesign.
good
scope: refinementchange: improve the existing dashboard's loading states and focus treatment
incumbent identity preserved while correcting a bounded surface. classification makes scope a stated decision — refinement fixes the named defect with copy, behavior, and identity intact; a true world-replacement must say so before work starts. small requests stay small; big changes arrive as visible, approvable projects.