Exercise 3: What Merging the Catalog and Registry Would Give Up — Possible Solution
====================================================================

Merging the two files would give up the real, independent review and
extension ability this chapter's own separation provides. The catalog
answers "what's allowed" and can be reasoned about (or shown to
someone reviewing what an AI model is permitted to generate) entirely
on its own, with no need to also understand how each component
actually renders. The registry answers "how does each type render"
and can change - swapping which real implementation backs a given
type, for example - without touching the list of allowed types at all.

Combining them into one file means every future change touches a
single, larger file mixing two genuinely different concerns (allowed
types vs. real implementations), making it harder to reason about
either one in isolation, and harder to, for example, swap out the
underlying component library (Shadcn) for a different one without
also risking changes to the catalog's own allowed-type list in the
same pass.

ANSWER: Merging them would give up the ability to review or change
"what's allowed" independently of "how it renders" - the catalog can
be reasoned about on its own without touching rendering details, and
the registry's own implementations can change without touching the
allowed-type list. A single merged file would mix these two genuinely
different concerns together, making each harder to reason about or
change in isolation.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the real, practical flexibility (independent
review and change) the separation provides, matching the "why this is
its own file" reasoning already given for the catalog in this chapter.