Philosophy: how far "design framework" goes

A design framework has more layers than a component library:

Foundation   → generic UI atoms (Button, Card, Input, Dialog, Tabs, Select, ...)
Domain       → nutrition-specific components (MetricRing, MealEntry, MacroBar, ...)
Patterns     → reusable multi-component sections (a "Daily Summary" block, "Weekly Progress")
Templates    → full page compositions (a whole Dashboard, a whole Onboarding flow)

This is a legitimate model — Material Design, Polaris, and Carbon are all structured this way. The question this page settles: which of these layers does yemek actually commit to building now, and which stays a deliberately deferred idea, so it doesn't get relitigated from scratch in a future planning session.

Domain (Nutrition Components) — yes, build proactively

This is yemek's actual differentiator, and the one layer worth investing ahead of an immediate meal-tracker rework opportunity. That's safe here — unlike the layers below — for an architectural reason, not an aspirational one: every component already takes app-agnostic, typed props (value/goal/status, calories/protein/...), see Architecture: presentation-only. That prop-based contract is what makes a component reusable across different nutrition apps — yemek doesn't need a separate effort to "design for other apps."

• Candidates like MacroBar, WaterTracker, GoalBadge, NutritionLabel can be prototyped without an acute meal-tracker call site, as long as they represent genuinely universal nutrition concepts — not meal-tracker idiosyncrasies.
• Still build against realistic mock numbers (Histoire/demo/), not purely abstractly — the tokens → hero component → generalize → preview → dogfood workflow doesn't change, only the trigger for starting it gets slightly more permissive.

Foundation (generic UI atoms) — explicitly out of scope

Button, Dialog, Tabs, Select, Checkbox, DatePicker, Drawer, Sheet, Avatar, Tooltip — none of these are nutrition-specific. Any nutrition app (including a hypothetical future second consumer) is just as well served pulling these from Radix, shadcn, or Mantine. Building them ourselves is commodity work that doesn't differentiate yemek as anything — a generic Button doesn't make a kit "the nutrition design system" any more than not having one does.

• The "other nutrition apps" ambition doesn't change this calculus — it applies equally to every generic UI kit, so it isn't actually an argument specific to yemek's positioning.
• yemek's differentiation lives entirely in the nutrition-specific slice. Spending build effort on generic atoms already well-solved elsewhere actively distracts from that.
• Revisit only if a concrete meal-tracker ad-hoc atom gets flagged as an actual design smell worth reworking — the same "concrete rework opportunity" trigger every component in this kit has had so far, never "a complete framework should have this."

Patterns (composed sections) — deferred, not abandoned

A Pattern (e.g. a DailySummary: ring + stat tiles + meal list, always the same order/spacing/ animation) encodes an opinion about structure, not just a single value's presentation. That's the key difference from a Domain component: MetricRing's props generalize across apps because the ring itself doesn't change, only the numbers do. A Pattern's whole shape would need to change between, say, a calorie-counting app and an intermittent-fasting app (a fasting countdown timer isn't a variant of a progress ring — it's a structurally different concept) or a recipe-first app. Discovering what's actually invariant across nutrition-app dashboards requires seeing at least two real, independently-motivated examples — extracting a Pattern from meal-tracker alone (n=1) just re-packages its own HomeTab with a new name, not a generalized abstraction.

• A self-built demo does not substitute for that second data point. Building a fictional "fasting app" demo to justify a Pattern means inventing both the component and the requirements it has to satisfy — nothing forces the abstraction to be honest, unlike meal-tracker's own real, pre-existing constraints (the same demo/-vs-real-integration distinction the architecture guide draws for individual components applies one level up, to Patterns).
• What a demo can do well: a stress test. Building 2–3 deliberately different mock nutrition-app concepts (calorie counter, fasting timer, macro-only tracker) using only yemek's current Domain components is cheap and worth doing — it can reveal that a component doesn't stretch to a scenario (a ring failing to represent a countdown, say). That's a useful negative signal ("doesn't fit"). It can't produce a reliable positive signal ("this generalizes"), because the scenario's requirements were self-authored.
• Composition — which components combine into which section, in what order — stays app-level code (currently in meal-tracker's own tab components) until a genuine second, independently motivated consumer exists.

Templates (full pages) — deferred, same reasoning one level up

A Template only makes sense once multiple apps with genuinely different needs exist to compare. For a single real consumer, the "template" already exists: it's that app's actual page. Revisit together with Patterns, not before.

The constant underneath all four verdicts

No speculative abstraction. Every component in this kit so far exists because a concrete, ugly, ad-hoc piece of meal-tracker UI got reworked — never because "a complete framework should have this." The "other nutrition apps" ambition doesn't relax that discipline; it only shifts what counts as a concrete trigger for the Domain layer specifically (a universal nutrition concept is now a valid trigger on its own, without a meal-tracker call site) — it does not create a blanket license to build Foundation atoms or Patterns ahead of real need. That discipline is what has kept yemek focused and high-quality; abandoning it to chase a "framework" label faster would trade the thing that actually makes yemek valuable for the thing that makes it look impressive on a landing page.