variation by configuration, never by branch

Per-customer difference is where products fork. One business wants the offers in the sidebar, another wants them as a strip; one wants a denser grid. The fast answer is a branch, then a build flag, then a separate deployment, and then nobody can say which combination is live.

This change refused the fork. Two genuinely different menu-page arrangements were built from the same components, and which one renders is decided by a pure function over precedence: an explicit local override, then a specific business identity, then the standard arrangement. Pure matters. The decision is computed without a browser, so it is host-tested, and its precedence order is a reviewed declaration rather than an emergent property of wherever a conditional happened to be placed.

The composition discipline is what made it affordable. The denser arrangement is an optional mode on the existing list component, defaulting off, so every existing call site is untouched and behaves exactly as before. Difference is expressed by composing differently, not by copying.

The override exists for review convenience — an operator can look at the other arrangement without changing configuration — but the durable mechanism is the business identity, which lives in the same configuration every other surface already reads. Switching an arrangement is a configuration change, not a release.

And the honest ending: verification for that business was still pending its registration and deployment, so the commit records plainly that the surface was still serving the generic shell.

What it proves: structural difference per customer can be carried without accumulating versions of the product.